Skip to main content

9.8. Abort of a Task - Abort of a Sequence of Statements

danger

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

1

[An abort_statement causes one or more tasks to become abnormal, thus preventing any further interaction with such tasks. The completion of the triggering_statement of an asynchronous_select causes a sequence_of_statements to be aborted.]

Syntax​

2 
abort_statement ::= abort task_name {, task_name};

Name Resolution Rules​

3/5

Each task_name is expected to be of any task type[; each can be of a different task type.]

Dynamic Semantics​

4

For the execution of an abort_statement, the given task_names are evaluated in an arbitrary order. Each named task is then aborted, which consists of making the task abnormal and aborting the execution of the corresponding task_body, unless it is already completed.

4.a/2
ramification

Note that aborting those tasks is not defined to be an abort-deferred operation. Therefore, if one of the named tasks is the task executing the abort_statement, or if the task executing the abort_statement depends on one of the named tasks, then it is possible for the execution of the abort_statement to be aborted, thus leaving some of the tasks unaborted. This allows the implementation to use either a sequence of calls to an “abort task” run-time system primitive, or a single call to an “abort list of tasks” run-time system primitive.

5

When the execution of a construct is aborted (including that of a task_body or of a sequence_of_statements), the execution of every construct included within the aborted execution is also aborted, except for executions included within the execution of an abort-deferred operation; the execution of an abort-deferred operation continues to completion without being affected by the abort; the following are the abort-deferred operations:

6
  • a protected action;
    • 7
  • waiting for an entry call to complete (after having initiated the attempt to cancel it — see below);
    • 8
  • waiting for the termination of dependent tasks;
    • 9
  • the execution of an Initialize procedure as the last step of the default initialization of a controlled object;
    • 10
  • the execution of a Finalize procedure as part of the finalization of a controlled object;
    • 11
  • an assignment operation to an object with a controlled part.
12

[The last three of these are discussed further in 7.6.]

12.a
reason

Deferring abort during Initialize and finalization allows, for example, the result of an allocator performed in an Initialize operation to be assigned into an access object without being interrupted in the middle, which would cause storage leaks. For an object with several controlled parts, each individual Initialize is abort-deferred. Note that there is generally no semantic difference between making each Finalize abort-deferred, versus making a group of them abort-deferred, because if the task gets aborted, the first thing it will do is complete any remaining finalizations. Individual objects are finalized prior to an assignment operation (if nonlimited controlled) and as part of Unchecked_Deallocation.

12.b
ramification

Abort is deferred during the entire assignment operation to an object with a controlled part, even if only some subcomponents are controlled. Note that this says "assignment operation", not "assignment_statement". Explicit calls to Initialize, Finalize, or Adjust are not abort-deferred.

13

When a master is aborted, all tasks that depend on that master are aborted.

14

The order in which tasks become abnormal as the result of an abort_statement or the abort of a sequence_of_statements is not specified by the language.

15

If the execution of an entry call is aborted, an immediate attempt is made to cancel the entry call (see 9.5.3). If the execution of a construct is aborted at a time when the execution is blocked, other than for an entry call, at a point that is outside the execution of an abort-deferred operation, then the execution of the construct completes immediately. For an abort due to an abort_statement, these immediate effects occur before the execution of the abort_statement completes. Other than for these immediate cases, the execution of a construct that is aborted does not necessarily complete before the abort_statement completes. However, the execution of the aborted construct completes no later than its next abort completion point (if any) that occurs outside of an abort-deferred operation; the following are abort completion points for an execution:

16
  • the point where the execution initiates the activation of another task;
    • 17
  • the end of the activation of a task;
    • 17.1/5
  • a point within a parallel construct where a new logical thread of control is created;
    • 17.2/5
  • the end of a parallel construct;
    • 18
  • the start or end of the execution of an entry call, accept_statement, delay_statement, or abort_statement;
18.a
ramification

Although the abort completion point doesn't occur until the end of the entry call or delay_statement, these operations might be cut short because an abort attempts to cancel them.

19
19.a
reason

The start of an exception_handler is considered an abort completion point simply because it is easy for an implementation to check at such points.

19.b
implementation note

Implementations may of course check for abort more often than at each abort completion point; ideally, a fully preemptive implementation of abort will be provided. If preemptive abort is not supported in a given environment, then supporting the checking for abort as part of subprogram calls and loop iterations might be a useful option.

Bounded (Run-Time) Errors​

20/5

An attempt to execute an asynchronous_select as part of the execution of an abort-deferred operation is a bounded error. Similarly, an attempt to create a task that depends on a master that is included entirely within the execution of an abort-deferred operation is a bounded error. In both cases, Program_Error is raised if the error is detected by the implementation; otherwise, the operations proceed as they would outside an abort-deferred operation, except that an abort of the abortable_part or the created task does not necessarily have an effect.

20.a
reason

An asynchronous_select relies on an abort of the abortable_part to effect the asynchronous transfer of control. For an asynchronous_select within an abort-deferred operation, the abort might have no effect.

20.b

Creating a task dependent on a master included within an abort-deferred operation is considered an error, because such tasks could be aborted while the abort-deferred operation was still progressing, undermining the purpose of abort-deferral. Alternatively, we could say that such tasks are abort-deferred for their entire execution, but that seems too easy to abuse. Note that task creation is already a bounded error in protected actions, so this additional rule only applies to local task creation as part of Initialize, Finalize, or Adjust.

Erroneous Execution​

21

If an assignment operation completes prematurely due to an abort, the assignment is said to be disrupted; the target of the assignment or its parts can become abnormal, and certain subsequent uses of the object can be erroneous, as explained in 13.9.1.

22/5

NOTE 1 An abort_statement is best used only in situations requiring unconditional termination.

23

NOTE 2 A task is allowed to abort any task it can name, including itself.

24/5

NOTE 3 Additional requirements associated with abort are given in D.6.

Wording Changes from Ada 83​

24.a/3

This subclause has been rewritten to accommodate the concept of aborting the execution of a construct, rather than just of a task.

Wording Changes from Ada 2012​

24.b/5

Added points within parallel constructs to the list of abort completion points.