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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,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/08/07 Message-ID: <33E9AF97.296F@flash.net>#1/1 X-Deja-AN: 262817517 References: <33E09703.6852@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-08-07T00:00:00+00:00 List-Id: Don Harrison wrote: > > Ken Garlington wrote: > > :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. > > Not at all. It's more than an assertion - it's a fact. You may choose to > disbelieve that fact for whatever reason but that doesn't alter its truth. I hadn't realized we were dealing in terms of a "higher truth" that doesn't require argument or evidence. I never argue religion, so we'll have to just disagree on this one. > > :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. 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? I have a feeling that we're just not communicating on this issue. My experience is in real-time systems, and I think I'm just not properly conveying the issues involved in developing those systems. > 1) and 2) can be included. > > :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. Once I see an appeal to authority, I pretty much have to assume the discussion is over. We'll just have to agree to disagree on this as well. > > Don. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Don Harrison donh@syd.csa.com.au