Boost logo

Boost :

From: scleary_at_[hidden]
Date: 2000-08-11 14:25:54


> > I am fairly sure we can design a monitor/condition interface
> > that is no less efficient than the primitives.
>
> . . . 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.

How would you need anything more than just an event? Or is your "fair and
correct" definition guaranteeing first-come-first-serve?

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

I agree with this. The fact is, monitors are not the Holy Grail of MT
programming. They are just another sync prim, another tool, that we can
use. Keep a good collection of tools around; then you can use the right
tool for the right job. It's a good idea to keep the kids (i.e.,
programmers without MT experience) away from power saws ;), but that doesn't
mean we shouldn't ever use power saws. (Actually, in this case it's the
"simpler" sync prim's that are more dangerous).

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

I say keep both; who knows -- an OS may yet surface which provides only a
monitor. In which case I would have no problem implementing the other tools
in terms of this one.

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

I think it would only be harder because you & I are used to mutexes, CVs,
and semaphores. If we were already used to monitors, I think it would come
fairly naturally. OTOH, I would prefer to add a new technique to my
toolbox, and keep all my old tools too. :)

        -Steve


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk