Boost logo

Boost :

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

From: William Kempf <sirwillard_at_[hidden]>
> --- 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.

This is another reason I like my idea of wrapping up the lock,
wait, and notify in a single constructor. It means that the
user can't get into undefined behavior, and the implementer
has maximum freedom to optimize.

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

It strikes me now that in a "classic" monitor the conditions
must be declared as monitor members, therefore they must be
signaled from within a monitor. So the question of whether
there might be a race can never arise.

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