Re: Threads: monitors vs. primitives

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-11 16:57:55

--- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> From: "William Kempf" <sirwillard_at_m...>
> > --- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> > > ...
> > > I am fairly sure we can design a monitor/condition interface
> > > that is no less efficient than the primitives.
> > 
> > Hardly.  A monitor will require the functionality to wait.  In 
other 
> > words, it requires a CV...
> 
> It was only yesterday I hit on a way to provide for multiple
> conditions safely.  Here is my current interface (which I was
> going to put off posting) in which the monitor class can be a
> mutex or critical section, the lock class can do simple mutual
> exclusion, and the wait class can work with the condition class
> to provide multiple explicit queues. (WARNING, Uncompiled Code):

[lots of code deleted]

We still have a CV primitive here.  All that you've done is to nest 
it within another class.  IMHO, that's not an improvement if the goal 
is to only have a monitor type.  Basically you've only done two 
things:  renamed "mutex" as "monitor" and nest the condition class 
within the monitor class.  Nothing is safer here.

Also, I don't like the fact that the condition isn't tied to the 
monitor.  It's possible to declare a single condition and then wait 
on it in two seperate monitors.

I also don't know why you used a class for waiting.  The only benefit 
this gave you in your example was the fact that you could name the 
wait.  However, the CV and predicate should have been enough for this.

Your code did give me an idea, however.  I've been trying to figure 
out how you could tie the CV to the mutex and also require the mutex 
to be locked before calling wait.  Well, you could pass the mutex in 
to the CVs constructor for the first part, and place the wait() 
method in the lock, passing in the CV, for the second part.  We'll 
still have some pretty tight coupling in my mind with the lock 
needing to be a friend of the mutex and the CV a friend of the lock, 
but it seems "solid" to me at this point.