Subject: Re: [linux-audio-dev] Multithreaded programming for a poll model?
From: Chris Cannam (cannam_AT_all-day-breakfast.com)
Date: Fri Jun 18 2004 - 01:01:22 EEST
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
This archive was generated by hypermail 2b28 : Fri Jun 18 2004 - 00:35:44 EEST