Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-24 17:17:51

--- In boost_at_[hidden], "Greg Colvin" <greg_at_c...> wrote:
> From: William Kempf <sirwillard_at_m...>
> > --- In boost_at_[hidden], "Greg Colvin" <greg_at_c...> wrote:
> > > From: William Kempf <sirwillard_at_m...>
> > In corner cases this may not be true. For instance, trying to
> > implement a Win32 Event using a monitor the implementation of
> > () could be greatly optimized by using InterlockedIncrement to
> > the "boolean" flag to true and calling the CVs notify_all()
> > 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
> > this, I know. But the fact that it's going to be problematic to
> > any more than call it "undefined behavior" to call notify()
> > 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.

However, this puts restrictions on the user. This results in the
optimal code above not being an option. It also means that there's
only two places within the monitor that you can wait, the beginning
and the end. I can see design patterns where you'd wait in the

If there's truly a danger for undefined behavior I might be persuaded
to agree to a wait_and_lock object though it still bothers me that a
notify will be part of this scheme. It doesn't seem natural or
expressive enough.

> > No, I'm not. I can't see any others but that doesn't mean I'm
> > 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
> > this, with the pthread standard not only saying it's safe but
> > 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.

I tried to point that out earlier with my Monitor as a C++ language
extension. This is an artifact of it being a language extension and
isn't really a well defined requirement of the pattern. I'm still
left wondering if there is a race condition to be concerned with?

Bill Kempf

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