Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-14 11:09:54

--- In boost_at_[hidden], brent verner <brent_at_r...> wrote:
> On 14 Aug 2000 at 08:39 (-0500), jsiek_at_l... wrote:
> | William Kempf writes:
> | > I think it makes as much sense to nest the CV as it does the
> | > The CV can't exist with out the mutex, while the mutex can
> | > withou the CV. Further, the CV is going to be as dependent
> | > [ clip ]
> | > > > while (!full)
> | > > > lock.wait(cv);
> | > >
> | > > while (!full)
> | > > cv.wait(lock);
> | > >
> | > > makes a little more sense to me.
> | >
> | > It makes more sense because it follows the logic of the
> | > implementation. However, I think it makes sense to reverse
them in
> | > our own library because the lock is waiting on the condition.
> |
> | The fact that the Mutex concept can exist without the CV concept
is an
> | argument for my position, not yours ;) The Mutex concept should
> | make any mention of a CV. Having a CV typedef nested in Mutex, or
> | having a wait() function in the Mutex's lock would make the Mutex
> | concept dependent on the CV concept, which is the opposite of
what we
> | want. We want tight coupling, but it should go in the other
> A condition variable must always be associated with a
> mutex, to avoid the race condition where a thread prepares
> to wait on a condition variable and another thread signals
> the condition just before the first thread actually waits
> on it.
> Having the condition class derive from the mutex class will
> the required behavior from the (pthreads) condition variable.

The paragraph you quote is actually addressing the fact that
the "mutex" must be locked before you can wait on the CV. This is
addressed by the fact that the CV is passed a "lock" object instead
of the "mutex" (or the "lock" is passed the CV in its wait() if you
reverse it). Inheritance doesn't really seem appropriate here,
especially since it would lock us into a one-mutex to one-CV idiom.

I've thought carefully about what Jeremy has said, and it is a valid
argument. I still don't know that I agree with it, however. We've
nested the lock class within the mutex. Why? The mutex concept can
exist with out the lock concept (though that would require making
public lock/unlock methods... but I don't find that to be a
compelling enough reason to embed the lock). To my mind we nested
the lock because it depends strongly on the implementation of the
mutex. The same is true of the CV. I see no physical or logical
constraints placed on us by embedding the CV, while I like the
bundling. After all, the CV can't exist with out the mutex, so it
makes sense to make it an embedded type to me.

As for the other issue, whether to put wait() in the CV or the lock,
I think Jeremy has a stronger argument here. I still think that
conceptually it makes more sense to say lock.wait(cv), but the
coupling is better with cv.wait(lock) and since pthreads are closer
to the latter I can live with it.

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