Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.java.tech,comp.lang.c++,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!portc01.blue.aol.com!newsxfer3.itd.umich.edu!howland.erols.net!feed1.news.erols.com!news.ecn.uoknor.edu!munnari.OZ.AU!news.mel.connect.com.au!news.syd.connect.com.au!syd.csa.com.au!news
From: donh@syd.csa.com.au (Don Harrison)
Subject: Re: Short technology paper on O-O concurrency/multithreading/Internet
X-Nntp-Posting-Host: dev50
Message-ID: <E4G6wq.15x@syd.csa.com.au>
Sender: news@syd.csa.com.au
Reply-To: donh@syd.csa.com.au
Organization: CSC Australia, Sydney
References: <32e574ac.8696975@news.wr.com.au>
Date: Thu, 23 Jan 1997 06:19:37 GMT
Lines: 79
Xref: glinda.oz.cs.cmu.edu comp.lang.eiffel:17549 comp.object:60160 comp.software-eng:52849 comp.lang.java.tech:6248 comp.lang.c++:242352 comp.lang.smalltalk:49705

Kent Tong writes:

:Bertrand Meyer <bertrand@eiffel.com> wrote:
:
:>A new short paper summarizing the SCOOP approach to programming
:>concurrent applications - multithreaded, distributed etc. -,
:
:I may not be fully understanding the resynchronisation
:mechanism. Why do we have to query the object in order
:to resynchronise with it? 

No doubt Bertrand will correct me if this is wrong, but...

In SCOOP, an object resynchronises with a separate (concurrent) one depending 
on whether it *needs* to. If it doesn't need to, it doesn't care when a 
separate call completes. The situations in which the caller cares about 
completion are:

a) If the caller subsequently queries (calls a function in) the separate 
   object. The result returned may depend on changes caused by the separate call. 

   eg.  o: separate someclass
        ...
        o.do_something;                        -- starts here
        ...
        a := o.result_of_doing_something       -- caller waits till do_something 
                                               -- completes
        ...

   Note that if the separate call is itself a function, the caller will wait 
   till it returns:

   eg.  o: separate someclass
        ...
        if o.some_condition then               -- starts and completes here
        ...

b) If the calling routine itself completes. This is necessary to ensure
   that the separate objects it uses are not unlocked prematurely. 

:For example, all we want may
:be just to print a message after (not before) it has 
:finished:
:
:    o: separate someclass
:
:    ...
:    o.dosomething;
:    put_string("it has finished");

You are right in saying you must query the separate object to ensure completion:

    o.dosomething;
    if o.state_from_doing_something then       -- waits till dosomething completes
      put_string("it has finished")
    end

I can imagine a couple of reasons why you may object to having to do this:

1) You have to invent a function in "someclass" returning information about 
   the object's state when you may not otherwise need it. 

   That's true. However, it's probable that other (separate) objects apart 
   from the caller also need such state information so you would need a 
   function anyway. I can certainly think of examples in my own work where
   this would be true.

2) Resynchronisation is a side effect of making a subsequent query.

   I don't have a problem with this as you only *need* to resynchronise
   when you need to know about the separate object's state and you need to
   determine that through a query anyway.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au


