Re: Re: A simple monitor for Boost

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-08-10 23:42:19

>   From: Dietmar Kuehl <dietmar_kuehl_at_[hidden]>
>--- Kevlin Henney <kevlin_at_[hidden]> wrote:
>> Yes, I am not sure why we are having a discussion on monitors vs
>> mutexes. Mutexes (and conditions) provide us with a primitive layer
>> on which we can build the higher-level programming models. If you
>> like, monitors are applied mutexes/conditions.
>
>My understanding is that Greg says we don't need the primitives at all!
>Monitors are sufficient and the better tool: The primitives are error
>prone but people will use them if they are there. Thus, we should drop
>them in favour of the better tool improving overall code quality. I
>think this is a reasonable approach!

Monitors are indeed a higher-level approach, and I'm all in favour of
them. There's only one problem: how do you write a monitor when the API
primitives on offer are not monitor based? You need to use primitives.
Aha!

In other words if we want to build a useful monitor-based approach we
need to have the locking primitives available because (1) we don't have
monitor facilities on offer in most of our APIs, and (2) we don't have
them in the language. (1) and (2) mean that it is _impossible_ to write
a general monitor class in C++ without the author of a class also
introducing the relevant locking code. These locks are based on what?
Primitives. Sure we can wrap them, in fact, that is what I stated in an
earlier email: let us define a primitive layer that we can build on, and
then build on it -- monitor base classes with raw API code really do not
appeal to men.

I personally don't care that people make a mess of primitives: they are
entitled to do that, and the last thing I want is to have a high-level
model forced on me that is incorrect for the job. You need char * to
write string classes, and you need mutexes et al to write monitors.

>I'm all in favour of this approach assuming that Greg is right with the
>assertion that the primitives are not necessary and that monitors are
>indeed the better tool. 

IME this is not necessarily true, except in a pure comp sci env :-} They
are not interchangeable tools. We appear to be choosing between apples
and apple pie. If I can mix metaphors, I want to have my apples and to
eat my pie (OK, no I can't).

>   From: "Greg Colvin" <gcolvin_at_[hidden]>
>I don't want a primitive layer, because I have seen the damage
>such primitives allow.

I want atoms so that I can build compounds: it is up to the user whether
or not they indulge in irresponsible atom splitting.

>There a many monitor-based languages in which large applications
>and operating systems have been written.  There are also proofs
>that monitors, mutexes, and semaphores are formally equivalent,
>in the sense that given one you can write the others.

I did a masters in parallel computing a few years ago, and it seemed
that the one recurring theme in all the papers on concurrency
abstractions that I read is that they would all present examples of how
to emulate primitives :-> This does not mean this is the right way to
go: they were invariably awkward and, in most cases, were emulating
primitives that existed under the hood anyway -- just less efficiently!

>   From: Alan Griffiths <boost_at_[hidden]>
>There seem to be two approaches developing...
>
>The 'high road' design option is to aim for:
>
> 1) Tools sufficiently 'higher level' than the native primitives so that 
>    they can be implemented efficiently on different native API, and
>
> 2) directly support 'good' threading techniques.
>
>The 'low road' is to identify the sufficient subset of functional
>requirements to abstract the primitive operations.
>
>Whatever approach is adopted (the above are not mutually exclusive or
>exhaustive) one cannot expect to provide all the functionality that
>exists within any given native API.  (Iterators don't support all the
>functionality of the pointers that inspired them.)

I had assumed that we were taking both approaches.
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________