Re: Threads: monitors vs. primitives

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 
heavy
> >   weight. I have, however, no idea whether this is really the 
case.
> 
> 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 
monitors
> >   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.