Threads: monitors vs. primitives

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-08-11 08:32:44

Hi,

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.
- Solving certain kinds of problems using monitors is not the natural
  approach.
- Monitors have their own set of problems.
- 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.
- A specific kind of monitor, namely a type with certain atomic
  operatios, would be implemented differently.

To me this basically means that we should foster use of monitors
through means of documentations (yeah, I know, nobody is reading the
documentation anyway), that is, presenting monitors as the way to go.
At the same time, we should define a basic low interface which probably
covers all primitives (atomic operations, mutexes, condition variables,
thread local data, thread lifetime) and use these low level interfaces
to create tools like the necessary monitor support. Use of the low
level interfaces should be kind of deprecated, although not in the
sense of the standard: The interfaces will remain stable and supported
but it should be stated clearly that their intention is the portable
creation of higher level tools, eg. monitors, to be used in application
code, only.

=====
<mailto:dietmar_kuehl_at_[hidden]>
<http://www.dietmar-kuehl.de/>

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/