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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,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: 267865941 Sender: news@syd.csa.com.au References: <33F526A9.23E5@flash.net> Reply-To: donh@syd.csa.com.au X-Nntp-Posting-Host: dev50 Organization: CSC Australia, Sydney Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-19T00:00:00+00:00 List-Id: Ken Garlington wrote: :Don Harrison wrote: :> On protected types: :Actually, it promotes OO principles, since the reasons for the requeue are :often due to the internal implementation of the protected object, and thus :can be hidden from the caller. Actually, on having another look, it probably *is* okay. The situation with requeues seems roughly equivalent to the valid situation of a separate object executing one of its own operations. Reflexive queueing just seems a little weird. :> One thing I'm curious about is where the requeued call gets placed on the :> entry queue. I guess it must be placed on the head, rather than the tail, :> for this to work. Is that the case? : :All queues are generally FIFO. The tail, in other words. :> Out of interest, is there one queue per protected object or one queue per entry? : :One per entry (which is what you want, if you want the timing behavior to be :different based on the operation/entry called). So, how does the runtime system select which queue to take the next call from? Is it arbitrary? ..or the one for the first declared entry? ..something else? I think entries, by default, should be serviced in the order in which they are received by the object - which implies object-based, rather than entry-based queueing. This is how SCOOP works. :.. any entry can be requeued. Furthermore, it's not up to the caller or callee, :it's up to the protected object: The callee *is* the protected object. What do you mean by callee? :"A requeue_statement can be used to complete an accept_statement or entry_body, :while redirecting the corresponding entry call to a new (or the same) entry :queue. Such a requeue can be performed with or without allowing an :intermediate cancellation of the call, due to an abort or the expiration :of a delay." : :"A requeue_statement shall be within a callable construct that is either an :entry_body or an accept_statement, and this construct shall be the innermost :enclosing body or callable construct." : :Again, the internal timing/sequence requirements can be hidden within the :object. It makes the decisions based on its internal state, .. Seems okay. :> :> IMO, "requeue" is a wokaround to a design flaw in Ada's concurrency - namely :> :> locking at the object level. Further, it's a *deficient* workaround because :> :> supplier objects are forced to do things (do_y) that should be the :> :> responsibility of clients (do_something). I think I probably misunderstood requeue's purpose here. The criticism of object-level locking reamains valid, though. :> I think it will be fine for *any* size system. Obviously, it will require a :> different design approach to that used with Ada because of some fundamental :> differences. These differences make it both more restrictive (in reliability- :> enhancing ways) and less restrictive (in ways that enhance reuse and modelling :> integrity). : :The design approaches I describe didn't come with Ada. They've been around :since assembly days. The same issues are described in real-time courses :regardless of implementation language. : :It would be interested to take some examples from these courses, such as the :HAS Buoy, Cruise Control, and ATD/CWM case studies from the ADARTS material, :and have them coded in SCOOP and executed. I agree - it would. If I get a chance, I'll take a look. Where are they? Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au