Re: pthread help
- From: gaetanoortisi@xxxxxxxx
- Date: 10 Nov 2006 13:03:27 -0800
David Schwartz wrote:
I would recommend avoiding example code where you give a thread an
infinite amount of work to do and then try to change what it's doing.
It's a very unrealistic scenario -- threads much more typically finish
the jobs they're doing or continue working on a job until they can't
make further progress. Trying to artificially force a master/slave type
arrangement on threads just results in code that's nothing like real
world code.
How about having one thread that writes data to a file and one or more
other threads that give it data to write or command it to close the
file and open a new one or rewind to the beginning of the file.
That way, you can have a linked-list of jobs for the file thread to do.
A thread can acquire a mutex, add a job to the linked list, and then
unlock the mutex and signal the condition variable. The file thread can
lock the mutex, while the linked list is empty, block on the condtition
variable, then pop the head job off the queue and release the mutex. It
can then do whatever that job says, whether it's write the data or
whatever.
DS
No, suppose I have data stored on the buffer that represent media
contents (audio, video). You could have the possibility to rewind,
pause,
stop, restart, etc. on this contents. The job of the thread is to
output
these contents until a pause or stop command, in which case it has
to (exit, suspend itself , what is better?), and (restart or recreate)
in
case of a new play command. An approach could be (experimental)
a play loop that looks for a flag variable before it starts a cycle of
output,
and if the variable is negative, do dumb operations. However, about
me is not a good solution.
void thread_fun(void)
{
for (;;) {
if (flag) {
.....output .....
}
}
void run (void)
{
pthread_mutex_lock(&m);
flag=1;
pthread_mutex_unlock(&m);
}
void pause (void)
{
pthread_mutex_lock(&m);
flag=0;
pthread_mutex_unlock(&m);
}
.
- Follow-Ups:
- Re: pthread help
- From: David Schwartz
- Re: pthread help
- References:
- pthread help
- From: gaetanoortisi
- Re: pthread help
- From: David Schwartz
- pthread help
- Prev by Date: Re: "unconnected" UDP connections
- Next by Date: Re: "unconnected" UDP connections
- Previous by thread: Re: pthread help
- Next by thread: Re: pthread help
- Index(es):
Relevant Pages
|