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?