pthreads and the new operator for passing structure as argument

[nass]

this is a thought experiment.
i do not have the time to implement it and test it to see if it works
so i am relying on your good will:)
thank you in advance

im on a linux machine (slackware 10.2) on an i686 intell processor.
its my first attempt to convert a fileIO procedure, to a pthread so it
won't stall the execution of the code.
im going through an online tutorial

http://www.llnl.gov/computing/tutorials/pthreads/

that rightly suggests that when passing argument to a thread i should
generate an array and each thread will be given a reference to a cell
of this array. so far so good.

now fileIO procedure is called every 1-2 seconds but it could need to
go down to 100msec.. in any case i assume the worst case scenario that
one thread of fileIO is NOT completed before a next fileIO thread is
created.

now since the structure of data i pass in the thread is rather big , i
thought its best to use dynamic memory allocation instead of
initializing an constant array. assume the struct is

ThreadPass *pThrdArgs;

so i declare it as such.
in the constructor i say

pThrdArgs = new ThreadPass[1];

so as to allocate 1 structure in mem.
during execution and when the condition is met i do a
memcpy(pThrdArgs[pThrdIDindex],SensorData,sizeof(ThreadPass))

and i create the thread, run it and increment the pThrdIDindex. at the
very end of the thread execution i reset the
pThrdIDindex = 0 so that on the next fileIO procedure call,
pThrdIDindex will be either 0 (the thread has completed) or 1 in which
case it means it hasnt competed.

what i want to do is to check if the thread has finished execution (by
checking pThrdIDindex or any other means cause i know this way is not
bulletproof) and if it hasn't to somehow allocate space for
pThrdArgs[1], ie do
pThrdArgs = new ThreadPass[2];

or smth similar to allocate space for the next pThrdArgs, while still
keeping the data of the pThrdArgs[0] intact for the 1st thread call to
complete.

additionally and provided this can happen. how should i go about
deleting the pThrdArgs[0] data? will the pThrdArgs[1] remain alive?

thank you for your help
nass

[Rolf Magnus]

nass wrote:

this is a thought experiment.
i do not have the time to implement it and test it to see if it works
so i am relying on your good will:)
thank you in advance

im on a linux machine (slackware 10.2) on an i686 intell processor.
its my first attempt to convert a fileIO procedure, to a pthread so it
won't stall the execution of the code.

This is off-topic here. comp.lang.c++ discusses C++ as defined by the ISO
standard, which doesn't know anything about "linux", "i686" or "pthread".

Having that said, POSIX offers several different ways to do asynchronous I/O
without the need to resort to threads.

[Emmanuel Deloget]

On 14 fév, 13:56, "nass" <[e-mail]:

now since the structure of data i pass in the thread is rather big , i
thought its best to use dynamic memory allocation instead of
initializing an constant array. assume the struct is

ThreadPass *pThrdArgs;

so i declare it as such.
in the constructor i say

pThrdArgs = new ThreadPass[1];

so as to allocate 1 structure in mem.
during execution and when the condition is met i do a

memcpy(pThrdArgs[pThrdIDindex],SensorData,sizeof(ThreadPass))

You'd better std::copy(). But that's only an opinion.

<further explaination>

thank you for your help
nass

I don't get it. pThrdArgs = new ThreadPass[N]; allocates space for N
elements of type ThreadPass. These elements can't be deleted one by
one - you have to delete them all at once. So you can't just "delete
pThrdArgs[0];" - it doesn't have much sense, unless ThreadPass is a
pointer type and pThrdArgs[0] points to an object of type
"typeof(*ThreadPass)" (I know... silly notation). But if this is not
the case, "delete pThrdArgs[0];" will not even compile, as a
ThreadPass instance is not likely to be automatically casted to a
void*.

So, to be clear: I don't understand what you want to do.

Regards,

-- Emmanuel Deloget

[nass]

On Feb 14, 3:05 pm, Rolf Magnus <[e-mail]:

nass wrote:

this is a thought experiment.
i do not have the time to implement it and test it to see if it works
so i am relying on your good will:)
thank you in advance

im on a linux machine (slackware 10.2) on an i686 intell processor.
its my first attempt to convert a fileIO procedure, to a pthread so it
won't stall the execution of the code.

This is off-topic here. comp.lang.c++ discusses C++ as defined by the ISO
standard, which doesn't know anything about "linux", "i686" or "pthread".

Having that said, POSIX offers several different ways to do asynchronous I/O
without the need to resort to threads.

you are referring to the use of fstream and the << & >operators ?

[paul.joseph.davis]

On Feb 14, 9:20 am, "nass" <[e-mail]:

On Feb 14, 3:05 pm, Rolf Magnus <[e-mail]:

nass wrote:

this is a thought experiment.
i do not have the time to implement it and test it to see if it works
so i am relying on your good will:)
thank you in advance

im on a linux machine (slackware 10.2) on an i686 intell processor.
its my first attempt to convert a fileIO procedure, to a pthread so it
won't stall the execution of the code.

This is off-topic here. comp.lang.c++ discusses C++ as defined by the ISO
standard, which doesn't know anything about "linux", "i686" or "pthread".

Having that said, POSIX offers several different ways to do asynchronous I/O
without the need to resort to threads.

you are referring to the use of fstream and the << & >operators ?

I believe he's referring to things like select() and the other basic
non-blocking methods for reading from files.

You don't really mention what your thread is supposed to be doing.
But, most threaded implementations of reading from a file use the
standard producer/consumer model with condition variables.

http://docs.sun.com/app/docs/doc/806...e9h032r?a=view

That webpage looks like it has a description of the model towards the
bottom.

That being said, if what you're wanting to do is read some large file
and processes it as you read it, then you probably just want something
like select(). Or you could even jump to something like libevent.

HTH,
Paul Davis

[nass]

On Feb 15, 12:31 am, "[e-mail]"
<[e-mail]:

On Feb 14, 9:20 am, "nass" <[e-mail]:

On Feb 14, 3:05 pm, Rolf Magnus <[e-mail]:

nass wrote:
this is a thought experiment.
i do not have the time to implement it and test it to see if it works
so i am relying on your good will:)
thank you in advance

im on a linux machine (slackware 10.2) on an i686 intell processor.
its my first attempt to convert a fileIO procedure, to a pthread so it
won't stall the execution of the code.

This is off-topic here. comp.lang.c++ discusses C++ as defined by the ISO
standard, which doesn't know anything about "linux", "i686" or "pthread".

Having that said, POSIX offers several different ways to do asynchronous I/O
without the need to resort to threads.

you are referring to the use of fstream and the << & >operators ?

I believe he's referring to things like select() and the other basic
non-blocking methods for reading from files.

You don't really mention what your thread is supposed to be doing.
But, most threaded implementations of reading from a file use the
standard producer/consumer model with condition variables.

http://docs.sun.com/app/docs/doc/806...e9h032r?a=view

That webpage looks like it has a description of the model towards the
bottom.

That being said, if what you're wanting to do is read some large file
and processes it as you read it, then you probably just want something
like select(). Or you could even jump to something like libevent.

HTH,
Paul Davis

i looked some more into things and possibly what i need is aio_write()
of the aio.h header.
what the program is doing:
i am running a loop and when the condition is met (basically a timer)
a buffer gets appended to a file. every so often (another timer) the
filename is changed so the next write must create a new file and start
appending into that. it is really a timed Binary log.
i have managed to do that with stream to file operations (where file
is of type fstream), and i have also managed to do it with fopen().
but it is a requirement that the execution is not halted so i looked
into threads... and then i came across asynchronous write.

now looking into aio_write and the struct aiocb that it takes as input
argument, i see that i must provide a file descriptor instead of ther
usual FILE *, that fopen returns.

and i am wondering if i should be opening the file prior to
aio_write(), or just opening the file once for evey new filename (*ie
when the file doesnt exist), getting the file descriptor, and closing
the file, so that when the time for aio_write() comes , aio_write()
will open, write and close the file on its own.

any ideas?