Re: Monitor patterns, Win32 events and race conditions

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-07-02 09:07:00

> Schmidt and Pyarali have written about this:
> http://www.cs.wustl.edu/~schmidt/win32-cv-1.html

fyi.. [http://groups.google.com/groups?as_umsgid=[e-mail]]:

[...]
Louis Thomas <lthomas_at_[hidden]> wrote:

>Subject:  RE: Win32 Conditions
[...]
>Schmidt & Pyarali list many of these in their
>paper "Strategies for Implementing POSIX Condition Variables on Win32"
>[http://www.cs.wustl.edu/~schmidt/win32-cv-1.html], and, as they indicate,
>none of them are correct.
 ^^^^^^^^^^^^^^^^^^^^^^^^

>However, there is one that they did not mention
>that is interesting because it is correct. Here it is in pseudocode form:
>---------- Algorithm 1 ----------
>given:
>ex_mutex - mutex
>cond - autoreset event
>nWaiters - int
>
>wait(timeout) {
>   nWaiters++
>   bTimedOut=SignalAndWait(ex_mutex, cond, timeout)
>   lock ex_mutex
>   nWaiters--
>   return bTimedOut
>}
>
>signal(bAll) {
>   do (bAll?nWaiters:1 times) {
>     PulseEvent(cond)
>   }
>}
>---------- ---------- ----------
>This pseudocode assumes that ex_mutex is always held by the thread calling
>signal, but is easily corrected by adding a CritSec or mutex to protect
>nWaiters. I think that this algorithm meets all the requirements specified
>by PThreads. There is no signal stealing, double broadcast deadlocks, or
>spurious wake ups. (There may be spurious PulseEvents but they do not
cause
>wake ups.) It has the nice property that it requires the same number of
>sync
>objects as the Unix version. However, it has one major drawback that is
not
>even mentioned in the PThread spec. In Win32, a thread that is in the
>'suspended' state is not in the 'waiting' state. This means that if a
>thread
>is waiting on an auto-reset event but is suspended when the PulseEvent
>occurs, it will miss the notification because it was not really waiting on
>the event. Debuggers suspend and resume threads all the time. This means
>that single stepping a program while a signal occurs can very easily cause
>any number of wake ups to be missed and deadlock to occur. Because of this
>problem, this implementation is basically unusable. PThreads does not even
>say whether or not threads can be suspended, let alone how this should
>affect threads waiting on a condition.
.
.
.
regards,
alexander.