[linux-audio-dev] Multithreaded programming for a poll model?

Chris Cannam cannam at all-day-breakfast.com
Thu Jun 17 22:01:22 UTC 2004


On Thursday 17 Jun 2004 10:21 pm, Tim Hockin wrote:
> The consumer never sees that the condition was TRUE.  It goes to
> sleep and never wakes up.  Now add the mutex [...]

I think (correct me if I'm an idiot) that what Joshua's talking about 
is that the thread that's waiting for the signal had to have been 
doing something before it started waiting for the signal at all.

So, if it was doing a whole load of file read stuff, and then it 
finished doing that and entered pthread_cond_wait, and it turned out 
that someone else had signalled on the condition while it was doing 
the file reads and before it ever entered the wait -- what then?  
You'd miss the signal, obviously, and just as above, you'd never see 
that the condition was ever true.  What difference does it make, from 
the point of view of the thread expecting the signal, whether the 
signal arrived while it was busy or during that moment between busy 
and actively waiting for the signal?

I think associating a mutex with a condition _is_ relevant -- if the 
thread doing the signalling has to acquire a lock to do so, then that 
can guarantee the other thread isn't busy at the time.  In Rosegarden 
we don't bother with a lock at all in the RT thread, we just signal() 
and don't care if the signal is lost.  Is there any advantage to 
calling trylock() before doing that, or is signalling on a condition 
you have no mutex interest in an OK thing to do?


Chris




More information about the Linux-audio-dev mailing list