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: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public 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 From: Ken Garlington Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/31 Message-ID: <33E09703.6852@flash.net>#1/1 X-Deja-AN: 261217033 References: <33D7F7CD.3E36@flash.net> Reply-To: kennieg@flash.net Organization: Flashnet Communications, http://www.flash.net Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-31T00:00:00+00:00 List-Id: Don Harrison wrote: > > Ken Garlington wrote: > > :I responded elsewhere in this thread about difficulties in trying > :to accurately measure thread timings at the object level, > > As I've already explained, SCOOP *does* support thread-level timing. The fact > this has not yet been tested in a realtime system doesn't invalidate any > logical arguments made about it. No, but then again, saying "X *does* support thread-level timing" isn't a logical argument, it's an assertion. And assertions, in the absence of any experience (either general experience from the author, or specific experience with X in a real system) are not particularly useful. 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. 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. What's worse, #1's effect increases with the number of objects/calls to objects in the thread. As a result, it's not a particularly useful approach when dealing with thread timings (as opposed to object timings). (This IS backed up by empirical evidence, by the way!)