Contents Index Previous Next
D.9 Delay Accuracy
1
[This clause specifies performance requirements
for the delay_statement. The rules
apply both to delay_relative_statement
and to delay_until_statement. Similarly,
they apply equally to a simple delay_statement
and to one which appears in a delay_alternative.]
Dynamic Semantics
2
The effect of the
delay_statement for Real_Time.Time
is defined in terms of Real_Time.Clock:
3
- If C1
is a value of Clock read before a task executes a delay_relative_statement
with duration D, and C2
is a value of Clock read after the task resumes execution following that
delay_statement, then C2
- C1 >= D.
4
- 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.
5
{potentially blocking operation
(delay_statement) [partial]} {blocking,
potentially (delay_statement) [partial]} 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).
6
When a delay_statement
appears in a delay_alternative of
a timed_entry_call the selection
of the entry call is attempted, regardless of the specified expiration
time. When a delay_statement appears
in a selective_accept_alternative,
and a call is queued on one of the open entries, the selection of that
entry call proceeds, regardless of the value of the delay expression.
6.a
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
7
The implementation shall document the minimum
value of the delay expression of a delay_relative_statement
that causes the task to actually be blocked.
8
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.
8.a
Implementation defined: Implementation-defined
aspects of delay_statements.
Metrics
9
The implementation
shall document the following metrics:
10
- 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.
11
- 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.
12
- {lateness} {actual
duration} 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.
13
- 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.
14
32 The execution time of
a delay_statement that does not
cause the task to be blocked (e.g. ``delay 0.0;'' ) is of interest
in situations where delays are used to achieve voluntary round-robin
task dispatching among equal-priority tasks.
Wording Changes from Ada 83
14.a
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.
Contents Index Previous Next Legal