Re: Threads: monitors vs. primitives

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-11 17:38:28

--- 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:
> > > 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?

No reason not to.  In fact, doing so might make it easier to 
implement conditions that will work with different mutex types (such 
as the recursive mutex which will require multiple unlocks followed 
by the same number of locks).  I don't think this was a bad idea, 
necessarily, it's just not a first class monitor object.

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

Slight misunderstanding.  The CV must be tied to the lock that it's 
used on (unless someone has a valid reason to use a CV with multiple 
locks, but I can think of none and it would be problematic to do 
so).  I just don't want this tie to result in one-CV to one-mutex.
 
> > 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();

*confused*  Why should you signal the condition after waiting for 
it?  That sounds to me like you'll just wind up with a "busy wait" 
when you have multiple threads waiting on the condition.  Or am I 
missing something?
  
> > 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?

Not yet, but I gave an example of what I'm talking about in a reply 
to Jeremy on this list.