Delay guarantees

Delay guarantees

[fmanning]

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?

According to the Ada 95 style guide at adaic, "The Ada language
definition only guarantees that the delay time is a minimum." The guide
also warns against depending on achieving a particular delay, but to
the extent that a delay is achievable, the implication seems to be that
a minimum is guaranteed.

But in the LRM, in section D.9 on Delay Accuracy, the only applicable
requirement I can find is in paragraph 3. To paraphrase -- if you read
the clock before and after a delay statement, the time difference must
be equal or greater than the delay argument.

Suppose the delay argument is equivalent to a single clock tick, and
the delay is executed just before a tick? Can delay return just after
the tick? If so, the actual time delay could be essentially 0.

-- Frank Manning
-- NetMedia, Inc.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: Delay guarantees

[David C. Hoos, Sr.]

fmanning@my-dejanews.com wrote in message <7i1m4b$cb1$1@nnrp1.deja.com>...
>If you have a delay relative statement, does the delay argument
>guarantee a minimum delay? For example:
<snip>
>Suppose the delay argument is equivalent to a single clock tick, and
>the delay is executed just before a tick? Can delay return just after
>the tick? If so, the actual time delay could be essentially 0.
>
Well, I can't speak for other compilers, but I know that the VADS
compiler (Ada83) on IRIX added the value of one clock tick internally to
guarantee meeting the requirement.

Re: Delay guarantees

[Robert I. Eachus]

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

Re: Delay guarantees

[Bryce Bardin]

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

Re: Delay guarantees

[Robert I. Eachus]

Bryce Bardin wrote:
 
> 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_.

    If you are going that far, you really should quote the next
sentence:

    The time base associated with relative delays is as defined in D.9,
"Delay Accuracy" or is implementation defined.

    Translation:  If the compiler supports the real-time annex, you can
look it up.  Otherwise ask your vendor. ;-)

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...