Re: [boost] Re: Threads

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

From: William Kempf <sirwillard_at_[hidden]>
> ...
> That aside, the point is really that notify_all() should be included
> regardless of whether or not notify_one() is present or even
> encouraged.  So we're making a change to the classic model here,
> which seems reasonable.  If that's reasonable, then so might the
> change to allow for notify() outside of the monitor lock be
> reasonable.

Concurrent Pascal (Brinch Hansen's language) has both notify
and notifyAll, but I don't recall whether they are restricted
to being called in a monitor.  Anyone have a reference manual?

> ...
> > I'm not sure what efficiency is gained by allowing notify outside
> > the lock, but I am fairly sure there is a danger of a race.  Consider
> > what might happen if you unlocked the mutex just before your signal
> > calls above.  How to know that the condition being signaled is still
> > true when the wait ends?
>
> 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.

> 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?