9.8 Abort of a Task - Abort of a Sequence of Statements
abort_statement ::= abort task_name
Name Resolution Rules
is expected to be of any task type[; they need not all be of the same
For the execution of an abort_statement
the given task_name
are evaluated in an arbitrary order.
named task is then aborted
, which consists of making the task
and aborting the execution of the corresponding task_body
unless it is already completed.
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
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.
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:
a protected action;
waiting for an entry call to complete (after having
initiated the attempt to cancel it — see below);
waiting for the termination of dependent tasks;
the execution of an Initialize procedure as the
last step of the default initialization of a controlled object;
the execution of a Finalize procedure as part of
the finalization of a controlled object;
an assignment operation to an object with a controlled
[The last three of these are discussed further in
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.
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.
When a master is aborted, all tasks that depend on
that master are aborted.
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;
are abort completion points for an execution:
the point where the execution initiates the activation
of another task;
the end of the activation of a task;
a point within a parallel construct where a new
logical thread of control is created;
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
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.
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
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 might or might not have an effect.
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.
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
42 An abort_statement
should be used only in situations requiring unconditional termination.
43 A task is allowed to abort any task
it can name, including itself.
Wording Changes from Ada 83
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
Added parallel constructs as abort completion points.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe