Boost logo

Boost :

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
> > a while() loop instead of an if() statement. This is an idiom
> 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

Bill Kempf

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