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: f43e6,2c6139ce13be9980
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 1108a1,2c6139ce13be9980
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,3d3f20d31be1c33a
X-Google-Attributes: gid103376,public
From: Ken Garlington <kennieg@flash.net>
Subject: Re: Safety-critical development in Ada and Eiffel
Date: 1997/07/23
Message-ID: <33D6A5BC.12D4@flash.net>#1/1
X-Deja-AN: 258640273
References: <33CEA7C1.3761@flash.net> <EDrHBA.H0u@syd.csa.com.au>
Organization: Flashnet Communications, http://www.flash.net
Reply-To: kennieg@flash.net
Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel
Date: 1997-07-23T00:00:00+00:00
List-Id: <comp.lang.ada>


Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Richie Bielak wrote:
> 
> :> I always thought it would be nice to have postconditions of the form:
> :>
> :>         ensure
> :>                 execution_time < 10 -- 10 milliseconds, let's say
>            end
>            ^^^
>            my addition
> :>
> :> So an exception would be raised if the routine took too long
> :> to execute.
> :
> :Of course, you have to decide if "execution time" includes the time for
> :the postcondition (including any code that executes after the actual
> :test instruction)!
> 
> It would be the duration when the expression "execution_time" is evaluated.
> There would be no statements following the assertion so it should be accurate
> enough for most purposes. 

1. Why would there be no statements afterwards?
2. If there were assertions _before_ this one, would their time be
included?
3. How is the assumption "accurate enough" captured in an Eiffel
assertion? (_Would_
it be captured?)

> If not, you can apply a small compensating adjustment
> to the relational expression:
> 
>          ensure
>                  execution_time < 9.99  -- milliseconds
>          end

However, this compensation depends upon making assumptions of the
time it takes to do the assertions... and we want to avoid writing code
whose correctness depends upon assumptions about how fast the code runs,
right?

> 
> :We usually have such measurements _outside_ the code sequence being
> :measured (i.e., in the scheduler).
> 
> ..in which case, you'd presumably be subject to the timing inaccuracies of
> the scheduler, anyway.

But the timing inaccuracies of the scheduler are at the thread level.
Your
inaccuracies are at the object level. If a lot of objects are called in
the course of a thread's execution (or a few are called a lot of times),
your inaccuracies build. Mine don't (particularly if the start of the
thread is controlled by a high-accuracy timer/low-overhead interrupt
handler, which is typical for hard real-time systems).

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au