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