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):
> .. do work ..
> WaitForMultipleObjects(mutex, event, wait_all);
> .. do more work ..
> 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: http://www.cs.wustl.edu/~schmidt/win32-cv-
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk