Boost logo

Boost :

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())
    try {

       // ...

    } catch (...) {
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at