Date: 2001-07-05 08:44:35
--- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> Alexander Terekhov wrote:
> > > > http://www.acm.org/classics/feb96/
> > > >
> > > > "Monitors: An Operating System Structuring Concept
> > > > C.A.R Hoare..."
> > >
> > > Thanks. This seems to be another case of me reinventing the
> > > What he's describing there seems to be the concept I put in my
> > > library under the name Flag.
> > i do not think so.. condition variables are stateless and
> > they are working together with mutex providing atomic
> > unlock_and_wait semantics (with respect to other threads
> > and CV/mutex).
> I meant that my Flag == his Monitor, not Flag == CV. If you
> please explain what the difference is.
> > note that auto-reset event is simply a binary semaphore.
> > manual-reset events also have state. it is really difficult
> > to use events due to all sorts of race conditions with
> > respect to "program" state and event state.
> I keep seeing assertions to that effect, but I've never seen any
> to justify the claim. Could you please supply a logical argument
> of a bare take-my-word-for-it? (Your example using my RWL doesn't
> I did say it was newly written and poorly tested, I expected it to
> have some bugs.)
The key is that the external mutex (when talking about CV types, or
for a monitor it's the hidden mutex) must be unlocked during the
blocking period of a wait() *only*. In other words, the mutex is
locked before and after the wait, but not during. With an event
object as defined by Win32 you'd code this as:
The problem should be self evident from this. After you wait on the
event there's a possibility for a race in acquiring the mutex. When
the "event" is the change of some state by the time we can re-acquire
the mutex this state may no longer hold true.
If you really want in depth discussions about how the race conditions
occur with various implementations read the classic article on
building Win32 CV concepts posted earlier in this thread
(BTW, I posted this info earlier, along with other remarks, but it
appears to have disappeared into the ether. Too bad, because I had
other things to say, but I don't have time to go back and try and
recreate my response.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk