Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-12 17:27:02

--- In boost_at_[hidden], jsiek_at_l... wrote:
> William Kempf writes:
> >
> > class mutex
> > {
> > public:
> > typedef basic_lock<mutex> lock;
> > typedef basic_trylock<mutex> trylock;
> > typedef basic_timedlock<mutex> timedlock;
> > typedef basic_condition<mutex> condition;
> >
> > mutex();
> > };
> I agree that the mutex type needs to be tied to the condition
> type, but it doesn't seem right to nest the condition type in the
> mutex type. Perhaps the condition class should have a typedef
> for the mutex type, and use the explicit lock types in the
> implementation of wait(). Or maybe we should have a separate traits
> class.

I think it makes as much sense to nest the CV as it does the lock.
The CV can't exist with out the mutex, while the mutex can exist
withou the CV. Further, the CV is going to be as dependent
(actually, more) on the internal implementation of the mutex as the
lock is. I think I like the tight bundling here.

> > 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 pthreads
implementation. However, I think it makes sense to reverse them in
our own library because the lock is waiting on the condition.
> I've got a preliminary write up of ConditionVariable with this
> interface, incuding the buffer example (which was compiled
> and run using KCC and Solaris threads).

Good write up. Now it's time to work out the wrinkles I think.

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