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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-08-11 15:15:09

From: "William Kempf" <sirwillard_at_[hidden]>
> --- 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.

Well, you have to go to a little more trouble to *not* follow
the monitor pattern.  A "true" monitor requires a language
extension.  I don't think we are really that far apart, so I
would ask -- why not nest the condition class?

> 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.

You also didn't like having the condition tied to the monitor,
ot did I misunderstand?

> 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.

The main benefit is that the wait destructor signals the
condition.  So the wait class privides a shorthand for:

    while (predicate())
        entry_condition.wait();
    try {

       // ...

    } catch (...) {
       exit_condition.signal();
       throw;
    }    
    condition.signal();
 
> 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.

Code?