comp.lang.ada
 help / color / mirror / Atom feed
From: "Robert I. Eachus" <eachus@mitre.org>
Subject: Re: Delay guarantees
Date: 1999/05/24
Date: 1999-05-24T00:00:00+00:00	[thread overview]
Message-ID: <3749EE1A.94483DF@mitre.org> (raw)

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...




             reply	other threads:[~1999-05-24  0:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-05-24  0:00 Robert I. Eachus [this message]
1999-05-25  0:00 ` Delay guarantees Bryce Bardin
1999-05-28  0:00   ` Robert I. Eachus
  -- strict thread matches above, loose matches on Subject: below --
1999-05-20  0:00 fmanning
1999-05-20  0:00 ` David C. Hoos, Sr.
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox