Go to the first, previous, next, last section, table of contents.

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.

    Metrics

  4. The implementation shall document the following metrics:
    1. 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.
    2. 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.
    3. 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.
    4. 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

  1. Even though the abort_statement is included in the list of potentially blocking operations, See section 9.5.1 Protected Subprograms and Protected Actions, it is recommended that this statement be implemented in a way that never requires the task executing the abort_statement to block.
  2. 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.

    NOTES

  3. (27) Abortion does not change the active or base priority of the aborted task.
  4. (28) Abortion cannot be more immediate than is allowed by the rules for deferral of abortion during finalization and in protected actions.

Go to the first, previous, next, last section, table of contents.