Boost logo

Boost :

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
> > port. However, I've just discovered that we have a pretty
> > flaw in the condition class design that I'd like to shore up
> > anyone attempts a port from my implementation (it should also be
> > noted that Jeremy and some others have their own implementations
> > 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
> > to notify(). It would be nice if we could have some manner in
> > 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
> > thoughts on this?
> Earlier I suggested that the lock, wait condition, and notify could
> 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

Bill Kempf

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