Contents Index Search Previous Next
9.8 Abort of a Task - Abort of a Sequence of Statements
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
{expected type (abort_statement
task_name) [partial]} Each
task_name
is expected to be of any task type[; they need not all be of the same
task type.]
Dynamic Semantics
4
{execution (abort_statement)
[partial]} For the execution of an
abort_statement,
the given
task_names are
evaluated in an arbitrary order.
{abort (of a task)}
{abnormal task} {task
state (abnormal) [partial]} 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
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'' RTS primitive,
or a single call to an ``abort list of tasks'' RTS primitive.
5
{execution
(aborting the execution of a construct) [partial]} {abort
(of the execution of a construct)} 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;
{abort-deferred operation} the
following are the abort-deferred operations:
6
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
{unspecified [partial]}
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;
{abort completion
point} 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;
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
- the start of the execution of a select_statement,
or of the sequence_of_statements
of an exception_handler.
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
{bounded error (cause)
[partial]} 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.
{Program_Error (raised by failure
of run-time check)} 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.
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
{normal state of an object
[partial]} {abnormal state
of an object [partial]} {disruption
of an assignment} {erroneous
execution (cause) [partial]} 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
38 An abort_statement
should be used only in situations requiring unconditional termination.
23
39 A task is allowed to
abort any task it can name, including itself.
24
Wording Changes from Ada 83
24.a
This clause has been rewritten
to accommodate the concept of aborting the execution of a construct,
rather than just of a task.
Contents Index Search Previous Next Legal