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

[Tim Hockin]

On Thu, Jun 17, 2004 at 01:16:27PM -0700, Joshua Haberman wrote:
> > A  condition variable must always be associated with a mutex,
> > to avoid the race condition where a thread prepares to wait on
> > a condition variable and another thread signals the condition
> > just before the first thread actually waits on it.
> 
> Who cares if that happens?  In this case, the signal should just be
> ignored.  Why is this worse than having another thread signal the

Unless I am misunderstanding, it's a classic race condition.  Assume that
there is some period of time between when you start preparing to wait, and
when you are actually ON the waitqueue.  Look:

Consumer			Producer
- Check condition (=FALSE)
- Prepare to wait 1		- Set condition to TRUE, no waiters
- Prepare to wait 2
- Go to sleep

The consumer never sees that the condition was TRUE.  It goes to sleep and
never wakes up.  Now add the mutex:

Consumer			Producer
- Take mutex
- Check condition (=FALSE)
- Prepare to wait 1		- block on mutex
- Prepare to wait 2
- Release mutex			- Take mutex
- Go to sleep			- Set condition to true, 1 waiter
- Wake, block on mutex		- Release mutex
- Take mutex
- check condition (=TRUE)


See the difference.  The problem is that you can always block on the
mutex.