From: cjmchale@dsg.cs.tcd.ie (Ciaran McHale)
Subject: Re: comparing object-oriented platforms
Organization: DSG, Dept. of Computer Science, Trinity College Dublin
Date: Tue, 29 Sep 1992 10:53:14 GMT

In <1992Sep29.043418.16848@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:
>As far as Eiffel is concerned there have been a number of discussions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>on concurrency and some proposed implementation techniques.

Don't you mean to say "As far as lots of OO languages are concerned..."
Eiffel is not unique in being used as a host language to test ideas on
synchronisation.

Of the proposals I have seen for synchronisation mechanisms, for
whatever language, none are perfect. We (people doing research in this
area) have been making great progress over the last few years but don't
expect any OO language, Eiffel included, to have a wonderful
synchronisation mechanism "real soon now."


>A couple of the latest papers are from TOOLS USA August '92, Prentice Hall.
>
>1.  "Concurrency Annotations Improve Reusability", Klaus-Peter Lohr ( with an
>oomlaut), Freie Universitat (with oomlaut) Berlin
> email: lohr@inf.fu-berlin.de
>
>[...] This has been implemented in a system called CEiffel. [...]
>
>2. Another approach is given in the TOOLS USA, August '92 proceedings:
>   This is called
>
>" A concurrency mechanism for sequential Eiffel", Murat Karaorman, John Bruno
>University of California, Sanata Barbara,
>email: murat@cs.ucsb.edu, bruno@cs.ucsb.edu
>
>[...] So no syntactic extension of the Eiffel language is required.

Whether or not a particular approach to synchronisation requires the
addition of an extra keyword or a change in syntax is not something
that I tend to worry about since there are other issues which seem more
important, e.g., the synchronisation mechanism's expressive power, its
compatability with inheritance and how it facilites/hinders code reuse,
does it support intra-object concurrency. I think it is more important
to solve these problems and then afterwards try to fit the resultant
mechanism into existing languages with a minimum of syntactic
disturbance. (Of course, this attitude of mine is of little help to
those who want a language *now* which they can use for concurrent OO
programming (COOP). But you must accept that whatever COOP langauges
which are available now or "real soon now" are certainly going to be
far from perfect.)



>It seems to me that we are going to see more of this type of approach
>[using multiple inheritance and introducing new concepts (such as
>concurrency/synchronisation) via new class types] to
>add new capabilities to the Eiffel language without having to make
>fundamental changes to the language syntax every time. It illustrates
>the capaability of Eiffel's conceptual extension into new domains because
>although you are not adding new syntax you are adding new TYPES to the
>language, together with their relevant operators and constraints.

One major problem I see with any synchronisation mechansism for Eiffel
which tries to support internal concurrency is the conflict between
internal concurrency and the evaluation of pre/postconditions. (What are
the semantics for evaluating pre/postcondition when instance variables,
which they access, are being updated by a thread executing an operation
of the object?) From my reading, it seems that CEiffel doesn't address
this issue. (I haven't read the paper by Karaorman & Bruno so I don't
know if they have a solution for this.)

I'm not sure whether or not this problem can be solved without having to
make "fundamental changes" to the language as you would like to
believe.


Ciaran.
-- 
Ciaran McHale                                                             ----
Department of Computer Science, Trinity College, Dublin 2, Ireland.       \bi/
Telephone: +353-1-7021539 FAX: +353-1-772204 email: cjmchale@dsg.cs.tcd.ie \/
Xref: sparky comp.object:3780 comp.lang.smalltalk:1971 comp.lang.eiffel:1197