Re: [boost] Re: Threads: monitors vs. primitives

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-08-11 17:04:29

From: <jsiek_at_[hidden]>
> 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.
> 
>  > while (!full)
>  >    lock.wait(cv);
> 
> while (!full)
>   cv.wait(lock);
> 
> makes a little more sense to me. 

I still think we are going overboard on the genericity here.
The mutex, lock and condition classes will need to be written
to work together if they are going to work well.

> 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

Looks good.  The names notify() and notify_all() might have some
advantages in familiarity over signal_one() and broadcast().