Contents Index Search Previous Next
D.6 Preemptive Abort
1
[This clause specifies requirements on the immediacy
with which an aborted construct is completed.]
Dynamic Semantics
2
On a system with a single processor, an aborted
construct is completed immediately at the first point that is outside
the execution of an abort-deferred operation.
Documentation Requirements
3
On a multiprocessor, the implementation shall
document any conditions that cause the completion of an aborted construct
to be delayed later than what is specified for a single processor.
3.a
Implementation defined: On
a multiprocessor, any conditions that cause the completion of an aborted
construct to be delayed later than what is specified for a single processor.
Metrics
4
The implementation
shall document the following metrics:
5
- The execution time, in processor clock
cycles, that it takes for an abort_statement
to cause the completion of the aborted task. This is measured in a situation
where a task T2 preempts task T1 and aborts T1. T1 does not have any
finalization code. T2 shall verify that T1 has terminated, by means of
the Terminated attribute.
6
- On a multiprocessor, an upper bound
in seconds, on the time that the completion of an aborted task can be
delayed beyond the point that it is required for a single processor.
7
- An upper bound on the execution time
of an asynchronous_select, in processor
clock cycles. This is measured between a point immediately before a task
T1 executes a protected operation Pr.Set that makes the condition
of an entry_barrier Pr.Wait true,
and the point where task T2 resumes execution immediately after an entry
call to Pr.Wait in an asynchronous_select.
T1 preempts T2 while T2 is executing the abortable part, and then blocks
itself so that T2 can execute. The execution time of T1 is measured separately,
and subtracted.
8
- An upper bound on the execution time
of an asynchronous_select, in the
case that no asynchronous transfer of control takes place. This is measured
between a point immediately before a task executes the asynchronous_select
with a nonnull abortable part, and the point where the task continues
execution immediately after it. The execution time of the abortable part
is subtracted.
Implementation Advice
9
Even though the
abort_statement
is included in the list of potentially blocking operations (see
9.5.1),
it is recommended that this statement be implemented in a way that never
requires the task executing the
abort_statement
to block.
10
On a multi-processor, the delay associated with
aborting a task on another processor should be bounded; the implementation
should use periodic polling, if necessary, to achieve this.
11
27 Abortion does not change
the active or base priority of the aborted task.
12
28 Abortion cannot be more
immediate than is allowed by the rules for deferral of abortion during
finalization and in protected actions.
Contents Index Search Previous Next Legal