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.3 required=5.0 tests=BAYES_00, 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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,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/13 Message-ID: X-Deja-AN: 263909601 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev50 References: <33E9AF97.296F@flash.net> 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-13T00:00:00+00:00 List-Id: Ken asked for evidence that SCOOP supports thread-level timing. Ken Garlington wrote: :I hadn't realized we were dealing in terms of a "higher truth" that :doesn't require argument or evidence. The evidence is in OOSC-2. I would leave it at that but I'll give an example because I may have been responsible for confusing you. :( Sorry if that's the case. I might have said that locking in SCOOP occurs at the object level. Anyone familiar with protected types would immediately assume this means objects are locked one-at-a-time (whenever they're called). SCOOP is fundamentally different in that groups of objects are locked together. As I'll explain later, this is an important distinction. Why are they collectively locked? Answer: So that processing can be performed under known conditions without interference from other threads (helping to avoid race conditions). Also, so that we know up-front that we have all the resources we needed (helping to avoid deadlock). When are they collectively locked? Answer: When they're supplied as parameters to an operation. What if they're not supplied as parameters? Answer: They always *are* (in the case of concurrent (separate) objects. In the case of sequential (non-separate) object, we don't care because we know they're local to the calling thread. See the example below.. :> :Futhermore, here is a counter-argument to writing timing assertions :> :at the object level: :> : :> :Using letters to denote objects, let's build a thread. The notation :> :x{object}y means that the object is executed between x and y times. :> :The arrows indicate that one object is executed before another object :> :in the sequence. (For simplicity, we'll neglect objects calling :> :objects). :> : :> :Thread: A -> B -> 1{C}4 -> D :> : :> :The max time for this thread is: A + B + 4*C + D, right? :> : :> :No! :> : :> :It also includes: :> : 1. the entry/exit code for each object (4 times that, for C), :> : 2. the time to start and stop the thread itself :> : 3. Any time between object invocations "stolen" by other threads. :> :> 3) doesn't apply to SCOOP because all objects are locked. : :(3) represents the time _in between_ object invocations. You might code your example in pseudo-SCOOP: Assuming separate (allocated to different threads) entities my_p: separate P my_q: separate Q my_r: separate R my_s: separate S and operation do_something (p: separate P; q: separate Q; r: separate R; s: separate S) is local start_time: time duration: ... do start_time := time_now p.a q.b loop (4 times) r.c end s.d duration := time_now - start_time ... end the call do_something (my_p, my_q, my_r, my_s) will do the required actions and measure the elapsed time. Note that all four objects are locked for the block between "do" and "end". This means that there is no intervening time between calls to them and there is no opportunity for any other threads to jump in and make a mess of things. Note that this offers more protection than Ada protected objects which are only locked on single object basis. As you will see later, this also removes the need for a "requeue" statement. :If you are saying that a thread (a series of object invocations) cannot be :interrupted at _any point_, then that pretty much eliminates :concurrency, doesn't it? No, it just means it's more controlled (and safer). There is a complementary library mechanism called "express messages" which allows pre-emption of threads. :I have a feeling that we're just not communicating on this issue. True. :My experience is in real-time systems, and I think I'm just not :properly conveying the issues involved in developing those systems. Likewise. :> :If you start the measurement before the call to A, and stop it :> :after the call to D, you only have to worry about #2 above :> :(which is usually fixed). If you do the measurement at the object :> :level, all three will skew your results. :> :> Not true. If you really want to get a clue on this, I suggest you get hold :> of OOSC-2 and read the chapter on concurrency. Sorry, Ken. I was a bit rude here. :Ken Garlington wrote (about Ada protected types): ::can requeue requests, I wrote: :IMO, the situations in which you would use "requeue" are better handled by :designing differently - perhaps by using an additional class. Sorry, this is wrong. The problem in Ada which "requeue" is designed to deal with doesn't arise in SCOOP because successive calls to the same separate object are atomic. That is, the object doesn't get unlocked between calls. For example, do_something (a: separate A) is do a.do_x a.do_y end does exactly what we expect. There is no need for do_x to "requeue" do_y. 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). :If anything, "requeue" probably encourages poor design. .. as I've just explained. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au