Boost logo

Boost :

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

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