Re: Threads

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-24 12:30:44

--- 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.
 
> > 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".

Bill Kempf