D.9 Delay Accuracy
Dynamic Semantics
The effect of the
delay_statement
for Real_Time.Time is defined in terms of Real_Time.Clock:
If C
1
is a value of Clock read before a task executes a
delay_relative_statement
with duration D, and C
2
is a value of Clock read after the task resumes execution following that
delay_statement,
then C
2
– C
1
>= D.
If C is a value of Clock read after a task resumes
execution following a
delay_until_statement
with Real_Time.Time value T, then C >= T.
A simple
delay_statement
with a negative or zero value for the expiration time does not cause
the calling task to be blocked; it is nevertheless a potentially blocking
operation (see
9.5.1).
Ramification: The effect of these requirements
is that one has to always attempt a rendezvous, regardless of the value
of the delay expression. This can be tested by issuing a
timed_entry_call
with an expiration time of zero, to an open entry.
Documentation Requirements
The implementation shall document the minimum value
of the delay expression of a
delay_relative_statement
that causes the task to actually be blocked.
Documentation Requirement: The minimum
value of the delay expression of a
delay_relative_statement
that causes a task to actually be blocked.
The implementation shall document the minimum difference
between the value of the delay expression of a
delay_until_statement
and the value of Real_Time.Clock, that causes the task to actually be
blocked.
This paragraph
was deleted.
Documentation Requirement: The minimum
difference between the value of the delay expression of a
delay_until_statement
and the value of Real_Time.Clock, that causes the task to actually be
blocked.
Metrics
The implementation
shall document the following metrics:
An upper bound on the execution time, in processor
clock cycles, of a
delay_relative_statement
whose requested value of the delay expression is less than or equal to
zero.
An upper bound on the execution time, in processor
clock cycles, of a
delay_until_statement
whose requested value of the delay expression is less than or equal to
the value of Real_Time.Clock at the time of executing the statement.
Similarly, for Calendar.Clock.
An upper
bound on the
lateness of a
delay_relative_statement,
for a positive value of the delay expression, in a situation where the
task has sufficient priority to preempt the processor as soon as it becomes
ready, and does not need to wait for any other execution resources. The
upper bound is expressed as a function of the value of the delay expression.
The lateness is obtained by subtracting the value of the delay expression
from the
actual duration. The actual duration is measured from
a point immediately before a task executes the
delay_statement
to a point immediately after the task resumes execution following this
statement.
An upper bound on the lateness of a
delay_until_statement,
in a situation where the value of the requested expiration time is after
the time the task begins executing the statement, the task has sufficient
priority to preempt the processor as soon as it becomes ready, and it
does not need to wait for any other execution resources. The upper bound
is expressed as a function of the difference between the requested expiration
time and the clock value at the time the statement begins execution.
The lateness of a
delay_until_statement
is obtained by subtracting the requested expiration time from the real
time that the task resumes execution following this statement.
Documentation Requirement: The metrics
for delay statements.
Wording Changes from Ada 83
The rules regarding a
timed_entry_call
with a very small positive Duration value, have been tightened to always
require the check whether the rendezvous is immediately possible.
Wording Changes from Ada 95
{
AI95-00355-01}
The note about “voluntary round-robin’, while still true,
has been deleted as potentially confusing as it is describing a different
kind of round-robin than is defined by the round-robin dispatching policy.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
