Re: [Boost-users] Thread events

...

Thanks for your replies.

To me boost::condition looks very much like the old event variable, except that it works together with a mutex. I am now wondering why you should lock a mutex before waiting for the condition? Is there a rationale about this? Also note that the wait() on the condition unlocks the mutex until you return from the wait call. That's not always obvious from the examples. Someone else mentioned the Butenhof book so I won't go down that

On 10/09/2005, at 2:12 AM, boost-users-request@lists.boost.org wrote: path; suffice to state that anyone that wants to do any thread programming absolutely must read that book. In fact, the book really is more about thread paradigms than pthreads. IMHO pthreads are more of a case study in the book. A quick example to fill in the time between you ordering the book and receiving it might help. Suppose you have a mutex for the purpose of protecting a variable. Suppose you must also wait on a condition because that variable isn't in a state that you need to progress. If you keep the mutex locked while waiting on a condition then no other thread will get the opportunity to modify the variable's value. To solve this many programmers will just unlock the mutex prior to waiting on the condition. However, the problem with this approach is that in the time between the mutex being unlocked, and the condition is waited on, another thread can come along, lock the mutex and change the variable. Thus you might be waiting on a condition that never occurs. Remember that conditions are generally signaled only to threads currently waiting on them or to the 1st thread that comes along and waits on a condition. Thus, if you're not waiting on a condition, you may never receive its signal. You may think that the chances of another thread coming along and upsetting your world are slim, but one day, it will happen and you'll be wanting to ignore that bug in your app 'cause it'll be hard to reproduce. pthread conditions are associated with mutexes so that they guarantee to unlock a mutex and wait on a condition without the chance of another thread coming along and doing what is described above. From an implementation perspective, I imagine pthread conditions enter into a critical section while they unlock a mutex and move to a wait state. As stated before, when you return from the condition, the mutex will be locked again, and you should re-test for your condition. Something like the following logic may help: ***** lock mutex while var not in state you need to proceed { wait on condition associated with mutex } unlock mutex do your stuff. ***** Note that it is also healthy to unlock your mutexes asap so as to reduce contention. 'hope that this helps. Cheers, -C