Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net