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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: donh@syd.csa.com.au (Don Harrison) Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/08/19 Message-ID: #1/1 X-Deja-AN: 267872680 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev50 References: <33f455bb.475760@wizard.pn.com> Organization: CSC Australia, Sydney Reply-To: donh@syd.csa.com.au Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-19T00:00:00+00:00 List-Id: Lee Webber wrote: :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. Looks like you think your bogometer's gone off again. :) As I said in my response to Ken, they're not model-specific so I don't intend being more specific. :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.) The solution I'm thinking of would use: - A staged approach in which intermediate data is computed. - Express messages to yield to higher "priority" threads. - A transaction-based approach to apply the results at the end on successful completion. I don't have the time to thrash out the details, but it should work and should be safe. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au