Re: [boost] Re: Threads

From: Greg Colvin (greg_at_[hidden])
Date: 2000-08-24 12:53:28

From: William Kempf <sirwillard_at_[hidden]>
> --- In boost_at_[hidden], "Greg Colvin" <greg_at_c...> wrote:
> > From: William Kempf <sirwillard_at_m...>
> > > Efficiency is gained because the lock doesn't have to be acquired.
> > > Acquiring a synch lock can be an expensive operation.
> > 
> > Right, but in normal usage you already have the lock.
> 
> In corner cases this may not be true.  For instance, trying to 
> implement a Win32 Event using a monitor the implementation of Signal
> () could be greatly optimized by using InterlockedIncrement to change 
> the "boolean" flag to true and calling the CVs notify_all() outside 
> of a monitor lock.  This is just the simplest example I can think 
> of... there may be more corner cases.  Not a great reason to require 
> this, I know.  But the fact that it's going to be problematic to do 
> any more than call it "undefined behavior" to call notify() outside 
> of a monitor lock is impetus enough for me to at least attempt to 
> define it as safe.

This is another reason I like my idea of wrapping up the lock,
wait, and notify in a single constructor.  It means that the
user can't get into undefined behavior, and the implementer
has maximum freedom to optimize.

> > > That particular race condition is resolved by the fact that we're in
> > > a while() loop instead of an if() statement.  This is an idiom  that
> > 
> > So much for that race then.  Are we sure there are no others?
> 
> No, I'm not.  I can't see any others but that doesn't mean I'm not 
> missing any.  It appeared that someone claimed the original paper 
> said there was, but I can't find anywhere in the paper that says 
> this.  I seem to be getting conflicting reports about the safety of 
> this, with the pthread standard not only saying it's safe but authors 
> on pthread programming encouraging you to do things this way "for 
> efficiency".

It strikes me now that in a "classic" monitor the conditions
must be declared as monitor members, therefore they must be
signaled from within a monitor.  So the question of whether
there might be a race can never arise.