Re: Threads: monitors vs. primitives

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).
> 
> http://www.lsc.nd.edu/~jsiek/ConditionVariable.html

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