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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,763df80c3d6aae03 X-Google-Attributes: gid103376,public From: Bryce Bardin Subject: Re: Delay guarantees Date: 1999/05/25 Message-ID: <374A093C.D352D3A1@home.com>#1/1 X-Deja-AN: 481738691 Content-Transfer-Encoding: 7bit References: <3749EE1A.94483DF@mitre.org> X-Accept-Language: en,en-GB,en-US,fr,fr-BE,fr-CA,fr-FR,fr-CH,de,de-AT,de-DE,de-CH,it,es,es-AR,es-CO,es-MX,es-ES Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@home.net X-Trace: news.rdc2.occa.home.com 927598899 24.7.50.190 (Mon, 24 May 1999 19:21:39 PDT) Organization: @Home Network MIME-Version: 1.0 NNTP-Posting-Date: Mon, 24 May 1999 19:21:39 PDT Newsgroups: comp.lang.ada Date: 1999-05-25T00:00:00+00:00 List-Id: "Robert I. Eachus" wrote: > > fmanning@my-dejanews.com wrote: > > > If you have a delay relative statement, does the delay argument > > guarantee a minimum delay? For example: > > > > Delay 0.5; > > > > Does this guarantee a minimum 500 ms delay? > > Short answer: Yes. > > There are three reasons why the RM says that this is a minimum > time: > > 1) There is usually a non-zero time associated with a context switch, > and > so there is a minimum delay that is not associated with the clock delay. > It is possible to ask for a shorter delay, but you will not get it. of > course, it is possible that a given switch will take longer... > > 2) All processors on which this task can run are currently running > tasks of equal or higher priority. The implementation is not required > to do an immediate task switch in this case. (This, of course, does not > apply if the delayed task is the only (eligable) task at the highest > priority. > > 3) Yes, the compiler is expect to delay "at least as long" as the > requested delay. If the clock used for delays has relatively long > ticks, you should expect the delay (if case 2 doesn't apply) to be > between the minimum number of ticks longer than the requested interval, > and two ticks longer than that. (Even if you request an exact multiple > of the clock interval, the allowance for the delay in 1 above can add > almost a whole tick.) Of course, in a good real-time implementation you > should expect that the clock used for computing delays allows timing to > the nearest microsecond or better. This does not mean that interrupts > can occur at that interval, just that the run-time can use a clock with > finer granularity to compute the minimum delay to request. > > -- > > Robert I. Eachus > > with Standard_Disclaimer; > use Standard_Disclaimer; > function Message (Text: in Clever_Ideas) return Better_Ideas is... Case 3) is, of course, the effect of section 9.6(20) of the Ada Reference Manual, which says, in part: For a delay_relative_statement, the expiration time is defined as the current time, in the time base associated with relative delays, plus the value of the delay_expression converted to the type Duration, and then _rounded up to the next clock tick_. (Emphasis added.)