- This clause describes various requirements for improving the response and
determinism in a real-time system.
- If the implementation blocks interrupts (see C.3)
not as a result of direct user action (e.g. an execution of a protected action)
there shall be an upper bound on the duration of this blocking.
- The implementation shall recognize entry-less protected types. The overhead
of acquiring the execution resource of an object of such a type (see
9.5.1) shall be minimized. In particular, there should not be any overhead
due to evaluating entry_barrier conditions.
- Unchecked_Deallocation shall be supported for terminated tasks that are
designated by access types, and shall have the effect of releasing all the
storage associated with the task. This includes any run-time system or heap
storage that has been implicitly allocated for the task by the
- The implementation shall document the upper bound on the duration of
interrupt blocking caused by the implementation. If this is different for
different interrupts or interrupt priority levels, it should be documented
for each case.
- The implementation shall document the following metric:
- The overhead associated with obtaining a mutual-exclusive access
to an entry-less protected object. This shall be measured in the
For a protected object of the form:
protected Lock is
function Read return Boolean;
Flag : Boolean := False;
protected body Lock is
procedure Set is
Flag := True;
function Read return Boolean
The execution time, in processor clock cycles, of a call to
Set. This shall be measured between the point just before
issuing the call, and the point just after the call completes.
The function Read shall be called later to verify that Set was
indeed called (and not optimized away). The calling task shall
have sufficiently high priority as to not be preempted during the
measurement period. The protected object shall have sufficiently
high ceiling priority to allow the task to call Set.
For a multiprocessor, if supported, the metric shall be
reported for the case where no contention (on the execution
resource) exists from tasks executing on other processors.
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Page last generated: 95-03-12