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: donh@syd.csa.com.au (Don Harrison) Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/29 Message-ID: #1/1 X-Deja-AN: 260237906 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev50 References: <33D9B8F9.4693018C@munich.netsurf.de> 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-07-29T00:00:00+00:00 List-Id: Joachim Durchholz wrote: :Paul M Gover wrote: :> :> Joachim Durchholz wrote: :> > Now *that* sounds bogus to me. The code should execute in exactly :> > the :> > same way, wether assertions are turned on or off. If you don't have :> > enough confidence in the compiler to generate code that runs :> > correctly, :> > why do you use a compiler at all? :> By definition, the code executes differently depending on whether :> asserions :> are turned on or off - because the assertion checking _is_ code! : :That's not what assertions are supposed to do. Of course assertions may :themselves be buggy, but the only possibility here should be that an :assertion signals an error where there is none. Since any software (sequential or concurrent) can contain timing-triggered branches, it's not only possible but probable that it will behave differently depending on whether assertions are turned on or off. Concurrent software typically contains such branches which may affect behaviour when extra processing overheads (for example, GC, assertions) are applied. Additionally, the non-determinism of these overheads may worsen this effect. This different behaviour does not indicate an error. However, another consequence of that overhead, which *is* erroneous, is that the software may fail to meet its specified timing constraints. This is the fundamental problem of using GC and assertions in timing critical contexts with current technology. Perhaps these barriers can be overcome by using more sophisticated technology.. :> In particular, there's likely to be some memory management going on in :> an :> OO system. Two possibilities: we could run out of memory in the :> assertion, :> or the memory management might take too long for some critical signal. : :Plus the assertion themselves will take time to check, which influences :timing. :I'm not in the hard real-time business (and have never been), so I might :be grossly off the mark. What I currently think is that no harm should :result if the code runs faster after disabling assertion checking. (Some :informed people in this group have claimed otherwise, but I haven't seen :convincing arguments why this should be the case.) As you say, the different behaviour is not a problem. However, the failure to meet timing constraints is. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au