Boost logo

Boost :

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?

Boost list run by bdawes at, gregod at, cpdaniel at, john at