Re: [boost] Threads: monitors vs. primitives

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-08-11 10:52:35

From: "Dietmar Kuehl" <dietmar_kuehl_at_[hidden]>
> 
> 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.

> - Solving certain kinds of problems using monitors is not the natural
>   approach.

I have yet to see such problems, but "natural" is a pretty
vague qualifier.  If your experience is only with more primitive
contructs they will seen natural.  When I programmed in FORTRAN
GOTO seemed natural too.

> - Monitors have their own set of problems.

An unsubstantiated claim, IMHO.  But if so, I would
expect the solution to be another higher-level construct,
such as message passing or remote procedure call.

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

> - A specific kind of monitor, namely a type with certain atomic
>   operatios, would be implemented differently.

I don't understand what you mean here.