- (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 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.
- (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)
- 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.
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.
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)
- 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.
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Copyright statement
Page last generated: 95-03-12
| 
| 
| 
| 