Re: Threads: monitors vs. primitives

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-11 18:03:59

--- In boost_at_[hidden], jsiek_at_l... wrote:
> 
> That's not prohibited, but that is OK. Unless I'm confused, the
> only thing we need to unsure is that the mutex used in the
> wait() is the one that is locked. We don't have to ensure 
> a single mutex for the condition varaible (pthreads doesn't).

*pauses to think*  I know that pthreads (and most other 
implementations) doesn't require this.  However, I always thought 
that doing so would lead to problems and was generally a design 
mistake.  I can't think of how it would be now, though, so maybe this 
is just hazy paranoia on my part.  If no one else knows why I have 
this feeling then I guess I'm fine with leaving that part out.  It 
even looks to me like we've got a very well defined model for all 
three types (mutex, condition and lock).

I'd still prefer to call it a mutex and not a monitor (probably 
mostly preference here), and I don't want to enforce a need to use 
inheritance of the mutex/monitor.  Beyond that, I think things look 
really good at this point.

BTW, I also think that nesting the condition within the monitor/mutex 
is a good idea, since the condition will have to vary it's 
implementation according to the type of mutex it cooperates with.

class mutex
{
public:
   typedef basic_lock<mutex> lock;
   typedef basic_trylock<mutex> trylock;
   typedef basic_timedlock<mutex> timedlock;
   typedef basic_condition<mutex> condition;

   mutex();
};

mutex mx;
mutex::condition cv;
mutex::lock lock(mx);

while (!full)
   lock.wait(cv);

Does anyone have further problems with these concepts?