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/2
This paragraph
was deleted.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.
3.b/2
Documentation Requirement:
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/2
{
AI95-00114-01}
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 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.
8.a/2
Documentation Requirement:
The metrics for aborts.
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.
9.a/2
Implementation Advice:
The abort_statement
should not require the task executing the 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.
10.a/2
Implementation Advice:
On a multi-processor, the delay associated
with aborting a task on another processor should be bounded.
11
35 Abortion does not change the active
or base priority of the aborted task.
12
36 Abortion cannot be more immediate than
is allowed by the rules for deferral of abortion during finalization
and in protected actions.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
