Subject: Re: [linux-audio-dev] Multithreaded programming for a poll model?
From: Tim Hockin (thockin_AT_hockin.org)
Date: Fri Jun 18 2004 - 00:21:21 EEST
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.
This archive was generated by hypermail 2b28 : Fri Jun 18 2004 - 00:15:55 EEST