Re: [Boost-users] Thread events

From: Christopher Hunt (huntc_at_[hidden])
Date: 2005-09-09 20:14:18

On 10/09/2005, at 2:12 AM, boost-users-request_at_[hidden] wrote:

>> 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  
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