Re: Threads

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

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

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

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