From: cjmchale@dsg.cs.tcd.ie (Ciaran McHale)
Subject: OO Concurrency Control (Was: OO Concurrency)
Organization: DSG, Dept. of Computer Science, Trinity College Dublin
Date: Wed, 14 Oct 1992 11:41:58 GMT

[Note: I'm following up in just comp.object since I don't think this
discussion is particular to either smalltalk or eiffel---Ciaran]


In <1992Oct13.125227.22956@bony1.bony.com> richieb@bony1.bony.com
(Richard Bielak) writes:
>cjmchale@dsg.cs.tcd.ie (Ciaran McHale) writes:
>>[...]
>>Notice that the potential concurrency is greater than than allowed by
>>labeling everything as either a "(whole object) reader" or "(whole
>>object) writer". By recognising that some operations only read/write
>>sub-parts of an object, while other operations read/write other
>>sub-parts we can have more potential for concurrency.
>
>I guess the question is, whether this is an "object-oriented" way to
>introduce concurrency into OOPLs. I'm not sure *what* the
>object-oriented way to add concurrency is, but your proposal doesn't
>feel right to me.

A slight semantic point. I'm talking about introducing _concurrency control_
(_synchronisation_ is the term I prefer) rather than _concurrency_.

As far as concurrency control is concerned, I think it is up to each
object to ensure its own consistency in the face of concurrent
invocations. Ideally, how the object does that should be its own
business, i.e., we want to keep the synchronisation protocol within an
object rather than have it spread among the clients of the object. Once
it is kept within the object, I think it is then primilarly an
implementation issue and its actual details need not be visible to
clients.

Actually, that's the way I *wish* it was since it would make life
easier. However, it is certainly possible for the synchronisation
policy of an object to affect its clients. Consider a client which
executes the following:

	repeat
		obj.write(...);
		obj.write(...);
		obj.read(...);
		obj.read(...);
	forever

If the synchronisation policy of "obj" is mutual exclusion then the
above code will run fine. On the other hand, if the synchronisation
policy of "obj" is "alternation" (i.e., allow write to execute, then
read, then write, then read, ...)---BTW, this would effectively make
"obj" a one element bounded buffer---then the above client code will
hang because it tries to do too many writes in succession.
[This example originates from Colin Atkinson]


At the ECOOP '92 workshop on OO concurrency there was some discussion of
this. Several people seemed to agree that:

	/1/ One task of synchronisation is to ensure the data
	    consistency of the object. Since it is often possible to
	    implement an object type in several different ways (e.g., a
	    buffer might use an array or a linked list) the
	    synchronisation is an implementation issue and should *not*
	    be visible in the object's type specification.

	/2/ The synchronisation on an object could affect the workings
	    of its clients (an example is given above). Therefore an
	    object's sychronisation *should* be visible in its type
	    specification.

The observant reader will notice that /1/ and /2/ contradict each other.
:-)

Research needs to be done to solve this paradox. Some examples of
current research in this direction include:

	o Klaus-Peter Lohr's work on CEiffel
	o The latest proposal for a synchronisation mechanism in Guide
	  (to be presented at an OOPSLA '92 workshop)

I'm sure I know of more research in this area but that's all I can
think of from the top of my head.

>Is a thread-of-control an object?

If you consider a thread to be an object then I guess that you would
also consider a thread of control to be an object. Since I don't think
of threads as objects I just view a thread of control as an (optional)
tool to help provide a synchronisation mechanism.


>P.S. Did you see the paper in Tools '92 "Concurrency Annotations
>     Improve Reusibility", by Klaus-Peter Lohr.

No, but I have read his OOPSLA '92 paper and his ECOOP '92 workshop
paper.

The proceedings of the ECOOP '91 workshop on OO concurrency are now
available. I have a paper in them. Here's the reference for anyone who
is interested.


@inproceedings{Comandos-Sync-14,
          author =	"Ciaran McHale and Bridget Walsh and Se\'n Baker and
			 Alexis Donnelly",
	   email =	"{cjmchale,baker,donnelly}@dsg.cs.tcd.ie,
			 bwalsh@iona.ie",
           title =	"{Scheduling Predicates}",
       booktitle =	"Proceedings of the ECOOP~'91 Workshop on Object-Based
			 Concurrent Computing",
          editor =	"M. Tokoro and O. Nierstrasz and P. Wegner",
           pages =	"177--193",
       publisher =	"Springer-Verlag",
            year =	1991,
           month =	jul,
            note =	"Published as Volume~612 of Lecture Notes in Computer
			 Science. Springer-Verlag. The paper is also available
			 as technical report TCD-CS-91-24, Department of
			 Computer Science, Trinity College, Dublin 2, Ireland.",
	abstract =	"In this report, we present a powerful new
			 synchronisation mechanism called {\em scheduling
			 predicates}. These predicates---{\em there\_are\_no},
			 {\em there\_exists\/} and {\em for\_all\/}---allow the
			 programmer to schedule the order of execution of
			 operations based on relative arrival times, values of
			 parameters, and built-in synchronisation counters.
		\par
			 Since many synchronisation problems are, in fact,
			 scheduling problems, these facilitate much simpler and
			 clearer solutions to such problems. We also show that
			 this mechanism subsumes and unifies the existing
			 declarative synchronisation mechanisms used in some
			 object-oriented languages, and extends the number of
			 problems for which a purely declarative approach is
			 possible."
}


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 \/