Monitor patterns, Win32 events and race conditions (was Re: Not keen on Boost.Threads?)

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, 
then
> 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 
condition?

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.

Bill Kempf