From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,2c6139ce13be9980
X-Google-Attributes: gidfac41,public
X-Google-Thread: f43e6,2c6139ce13be9980
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 103376,3d3f20d31be1c33a
X-Google-Attributes: gid103376,public
X-Google-Thread: 1108a1,2c6139ce13be9980
X-Google-Attributes: gid1108a1,public
From: leew@micrologic.com (Lee Webber)
Subject: Re: Safety-critical development in Ada and Eiffel
Date: 1997/08/15
Message-ID: <33f455bb.475760@wizard.pn.com>#1/1
X-Deja-AN: 264325920
References: <33F26189.B3E@flash.net> <EEw7vK.9DB@syd.csa.com.au>
Organization: Pioneer Global
Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel
Date: 1997-08-15T00:00:00+00:00
List-Id: <comp.lang.ada>


On Thu, 14 Aug 1997 07:38:08 GMT, donh@syd.csa.com.au (Don Harrison)
wrote:

>Ken Garlington wrote:
>
>:Don Harrison wrote:
     ...
>:It seems to me that, locking _all_ objects involved in an operation (without
>:regard to whether they guard a sensitive resource, such as a data store
>:that can be written by multiple threads) means that the latencies associated
>:with the threads goes up dramatically, particularly if the locking is
>:transitive.
>
>I was also concerned about this issue initially but came to the conclusion 
>that objects would be locked for just as long as they (safely) need to be.
>Where it's important to release a frequently used shared resource quickly, 
>various design strategies can be applied to minimise locking.
  ^^^^^^^^^^^^^^^^^^^

I would be interested in your expanding on this.  In particular, how
would you implement this in SCOOP:

        gain exclusive access to A
           perform time-consuming work using A and local resources
        gain exclusive access to A and B jointly
           perform work using A, B and local resources computed above
        release A, retain B
           perform time-consuming work using B and local resources
              computed above
        release access to B

making sure that neither A nor B is held when it is not needed.  (You
may assume that all competing processes attempt to acquire A and B in
the order above -- otherwise there is no solution other than the
trivial that avoids deadlock.)