From: cjmchale@dsg.cs.tcd.ie (Ciaran McHale)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: OO Concurrency
Keywords: wait-by-necessity
Date: 1 Oct 92 10:54:30 GMT
Organization: DSG, Dept. of Computer Science, Trinity College Dublin

In <1992Sep30.123309.7715@bony1.bony.com> richieb@bony1.bony.com
(Richard Bielak) writes:
>cjmchale@dsg.cs.tcd.ie (Ciaran McHale) writes:
>>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."

Just in case people have misunderstood me, I'll try to clarify what I
said previously.

	There has been a lot of progress made in the area of
	synchronisation mechanisms over the last few years. I am *not*
	knocking the progress that has been made. All I am saying is
	that there is still a lot more which needs to be done before we
	will have something which is "up to scratch."

By "up to scratch" I mean a synchronisation mechanism which is (i)
powerful in its own right and (ii) integrates cleanly with other
language constructs/concepts.


>One very neat idea for synchronization was proposed by D. Caromel. He
>called it "wait-by-necessity" (also called "lazy wait").

Wait-by-necessity has some semantics which I think are a bit strange.
For example, to quote from page 17 of [Caromel-1] (ref at the end of
this email):

	res := ob1.op1;
	res := ob2.op2;
	<use of res>

	In this situation, the first result (from obj1 or obj2) is
	[assigned] to res... If the second result comes back... it is
	lost. This asynchrony allows Project Team resolution.

Those semantics are different from the semantics you would expect in a
purely sequential language. I don't like the subtle difference. (I guess
that one person's neat idea is another's unsafe optimisation:-)



>>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?)
>
>Regarding the pre- and post-conditions, I thought of the following way
>of dealing with this problem. 
>
>You can divide features of a class into "querries" and "commands".
>Querries only read the object's attributes and return some value.
>Commands modify the object.

Indeed, that is one way to handle it. But it has some limitations:

	o The readers/writer (queries/commands as you call them) policy
	  may be artifically constraining the potential for concurrency.
	o Most likely it would be the programmer's responsibility to
	  take the pre-/post-conditions into account when writing the
	  synchronisation code for the object. I think this gives
	  programmers more than enough rope to hang themselves with.

Another possibility (as taken by Caromel) is for the language to
disallow internal concurrency within objects (but to allow for
concurrency between objects).



@article{Caromel-1,
          author =	"Denis Caromel",
           title =	"{Service, Asynchrony, and Wait-By-Necessity}",
         journal =	"Journal of Object Orientated Programming (JOOP)",
            year =	"1989",
           pages =	"12--22",
           month =	nov
}


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:3789 comp.lang.smalltalk:1981 comp.lang.eiffel:1201