Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-11 14:12:42

--- In boost_at_[hidden], "Greg Colvin" <gcolvin_at_u...> wrote:
> From: "Dietmar Kuehl" <dietmar_kuehl_at_y...>
> >
> > from the current discussion on Gregs proposal I conclude that it
is not
> > desirable to have monitors as the only means of synchronization.
I draw
> > the conclusion from the following statements:
> >
> > - For certain kinds of problems monitors are assumed to be too
> > weight. I have, however, no idea whether this is really the
> 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. A CV on some platforms is a very heavy
weight construct. For instance, to implement a CV on the Win32
platform correctly (i.e. it's both fair and correct) requires the use
of a mutex (or critical section), a semaphore and an event. This is
a fairly expensive construct. If what you need is a CV then you can
easily live with that cost, but if all you're doing is preventing
simultaneous access to a resource that's way too high of a cost. A
monitor, which combines the functionality of a mutex with a CV, is a
pretty expensive synchronization object.

To my mind, you can not do with out the mutex. You could replace the
CV with a monitor, but in that case all you've done is tied a CV and
a mutex together in such a way that they can't be used seperately.
This is fine as long as we don't care about allowing some more
efficient (though harder to code right) constructs by using multiple
CVs with a single mutex. So I see the choice as being whether or not
to eliminate the CV in favor of only a monitor or should we include
both. Either way, the mutex must stay.

> > - To implement monitors in the first place, we need the primitives
> > anyway, especially as there are apparently variations of
> > need more than just one condition variable.
> There are different ways of implementing monitors with
> different primitives, and platforms vary in what primitives
> they provide and how efficiently they are implemented.
> This is another reason for not exposing the primitives.

That's true only if you require that the monitor be constructed on
top of the other primitives we've implemented. In nearly every case
you'll probably be more efficient if you use the native primitives to
build all of these. Not that I think that efficiency is the issue
here, at least not efficiency at this level.

Besides, you didn't address the issue here. You've made it
impossible to have a multiple condition monitor (or some other
construct) unless the library provides it. We can't presume to
provide all possible synchronization types in the library, so should
provide the most basic ones at the very least to insure that other
types can be easily modeled. What happens in two years when we find
some new synchronization technique that's safer and easier to use
than the monitor and all we have is the monitor type in our library?
It's going to be harder and less efficient to model the new technique
off of only this one synchronization object.

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