Boost logo

Boost :

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
> > it within another class. IMHO, that's not an improvement if the
> > is to only have a monitor type. Basically you've only done two
> > things: renamed "mutex" as "monitor" and nest the condition
> > 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
> > 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
> > this gave you in your example was the fact that you could name
> > wait. However, the CV and predicate should have been enough for
> 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
> > out how you could tie the CV to the mutex and also require the
> > to be locked before calling wait. Well, you could pass the mutex
> > to the CVs constructor for the first part, and place the wait()
> > method in the lock, passing in the CV, for the second part.
> > 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
> > 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.

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