Re: how to implement monitor

["Mark Lundquist" <up.yerz@nospam.com>]

"Dale Stanbrough" <dale@cs.rmit.edu.au> wrote in message
news:dale-82F8BD.17523218062001@mec2.bigpond.net.au...
> ArekB wrote:
>
> > hi
> > I use "protected type" to implement monitor, but how to implement
> > conditional variables and function "signal" and "wait"
> > Thanks in advance
>
> You don't.

Well, it *can* be done, of course...

> If you do this, then you will not be following the
> proper mechanism for dealing with concurrency in Ada.

Quite so... and let me enlarge upon that for the benefit of the original
poster.  A handful of points:

1) Condition variables are not monitors!  Remember that the original
Hoare-style monitor concept is a language construct.  CVs allow for an
*approximation* of monitors in languages which lack intrinsic concurrency
support.

2) Ada protected types really *are* monitors!  (and other, older
languages -- e.g. Mesa, Modula-2 -- had monitors, too).

3) In general, you would not want to settle for a CV/mutex solution when you
have real monitors like Ada protected types.

4) To use CVs, you have to have mutexes too.  Both can be implemented using
Ada protected types.  In terms of efficiency, the final solution is going to
be inferior to a design that used protected types the way they're meant to
be used.  The Ada implementation is going to implement protected types the
most efficient way it can; layering a CV/mutex implementation over the top
of that would be a case of "abstraction inversion".  I can see someone doing
it as an academic exercise, but that's about all.

5) If you really want to use CVs/mutexes, it's more efficient to bind to the
services provided by an OS or threads library.  (The POSIX Ada binding
includes the POSIX threads stuff...)

So to sum it up, it can be done, but then... you are approximating monitors
(as is always the case with CVs) using an abstraction that in turn is
implemented in terms of real monitors.  That would be the "worst of both
worlds" because it loses in efficiency, safety, and expressiveness/clarity.
Designing using protected types wins on all three.

Have fun,
Mark Lundquist