Re: Threads

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-18 14:28:07

--- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> From: "William Kempf" <sirwillard_at_m...>
> > ...
> > I'm familiar enough with pthreads to know that it should be an 
easy 
> > port.  However, I've just discovered that we have a pretty 
serious 
> > flaw in the condition class design that I'd like to shore up 
before 
> > anyone attempts a port from my implementation (it should also be 
> > noted that Jeremy and some others have their own implementations 
that 
> > vary from mine to one degree or another, and they've used thread 
> > libraries other than Win32 as the basis).
> > 
> > The problem with the CV is that we've only insured that the 
> > associated mutex is locked in the call to wait() but not in the 
call 
> > to notify().  It would be nice if we could have some manner in 
which 
> > we can insure that we've locked the mutex at compile time for 
both of 
> > these, though I think we'll likely have to settle for an 
exception at 
> > run time.  If you've seen Jeremy's documentation maybe you have 
some 
> > thoughts on this?
> 
> Earlier I suggested that the lock, wait condition, and notify could 
be
> combined into a single object with a templated constructor.

This doesn't address the problem.  Just combining them into a single 
object won't solve the problem of needing the mutex to be locked 
during calls to wait() and notify().

Besides, the lock can't be combined in this way, and combining the 
mutex and condition forces us to a one-to-one relationship.  Since it 
can be very beneficial to use multiple conditions with a single mutex 
I don't want to combine these two concepts.  Not to mention not 
wanting to force the overhead of a condition on everyone that uses a 
mutex.

Bill Kempf