Re: [boost] Re: A simple monitor for Boost

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

From: "Kevlin Henney" <kevlin_at_[hidden]>
> In message <8mui65+jteo_at_[hidden]>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >I've taken a look at the classic 1974 paper by Hoare, and this paper 
> >has a very good example of why the simplistic monitor you've 
> >described can not be a replacement for conditions.  He's got an 
> >example of a read/write lock implemented using his concept of a 
> >monitor.  The implementation requires two conditions.  I'm not sure 
> >that a monitor deserves first class implementation in a C++ library 
> >given this.  The monitor as Hoare describes it may simply be a 
> >programming idiom used with mutexes and conditions.  That's 
> >definately something that's up to debate, but I think I've proven to 
> >myself that we can't do with out the primitives mutex and condition 
> >just because we include a monitor.

Hansen shows how to implement this same example with a single
implicit condition.  Using explicit conditions is a small
performance enhancement, about which Hoare warns "the
introduction of condition variables makes it possible to write
monitors subject to the risk of deadly embrace".  That said, I
am on the fence as to whether to propose condition variables.
 
> 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.

I don't want a primitive layer, because I have seen the damage
such primitives allow.

> So without synchronisation primitives in our library we can't build
> monitors, but with only monitors we can't easily build concurrent apps
> :->

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.

> We should provide the primitives that allow monitors and other
> approaches to be built, as well as providing some of these higher-level
> concepts directly in the library.

I'm arguing that the monitor concept is well-established as the
best practice for concurrent programming in imperative langauges,
and that lower-level primitives are not needed.