Contents Index Search 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 Search Previous Next Legal