Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-07-02 09:03:53

--- In boost_at_y..., "Jeff Paquette" <paquette_at_m...> wrote:
> williamkempf_at_h... wrote:
> <<
> Events are much more error prone and can't be used in a monitor
> pattern. The reason for this is that they don't work in conjunction
> with an external mutex. A condition variable does. You lock the
> mutex first, then possibly do some work with shared data, then wait
> on the CV. The wait operation first unlocks the external mutex,
> blocks until the CV is signaled, then re-locks the mutex. This
> insures that you retain exclusive access to shared data before and
> after a wait, but not during. You can't do the same thing with an
> event with out causing race conditions.
> >>
> PMFJI, but doesn't this (Win32 pseudo code):
> WaitForSingleObject(mutex);
> .. do work ..
> WaitForMultipleObjects(mutex, event, wait_all);
> .. do more work ..
> ReleaseMutex(mutex);
> ReleaseMutex(mutex);
> work in the same fashion as the monitor mentioned above sans race

Nope, but the reasons are *very* subtle. Actually, you have a big
bug in the above example... you don't unlock the mutex before
waiting. Instead of a race condition this results in a deadlock,
which is much worse. Fix this and you'll get the race condition
instead, and to understand why I'll send you to the original article
on this subject at:
1.html. You should note that Alexander Terekhov found some bugs in
the implementation used in this article, so what pthreads-win32 and
Boost.Threads use is more complicated yet.

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at