9.3 Task Dependence - Termination of Tasks
task (other than an environment task — see 10.2
on one or more masters (see 7.6.1
If the task is created by the evaluation of an
for a given access type, it depends on each master that includes the
elaboration of the declaration of the ultimate ancestor of the given
If the task is created by the elaboration of an
it depends on each master that includes this elaboration.
Otherwise, the task depends on the master of the
outermost object of which it is a part (as determined by the accessibility
level of that object — see 3.10.2
and 7.6.1), as well as on any master whose
execution includes that of the master of the outermost object.
The master of a task created by a return statement
changes when the accessibility of the return object changes. Note that
its activation happens, if at all, only after the function returns and
all accessibility level changes have occurred.
Furthermore, if a task depends
on a given master, it is defined to depend on the task that executes
the master, and (recursively) on any master of that task.
A task is said to be completed
when the execution
of its corresponding task_body
is completed. A task is said to be terminated
when any finalization
of the task_body
has been performed (see 7.6.1
). [The first
step of finalizing a master (including a task_body
is to wait for the termination of any tasks dependent on the master.]
The task executing the master is blocked until all
the dependents have terminated. [Any remaining finalization is then performed
and the master is left.]
When both conditions are satisfied, the task considered
becomes completed, together with all tasks that depend on the master
considered that are not yet completed.
Any required finalization
is performed after the selection of terminate_alternative
The tasks are not callable during the finalization. In some ways it is
as though they were aborted.
8 The full view of a limited private type
can be a task type, or can have subcomponents of a task type. Creation
of an object of such a type creates dependences according to the full
10 The rules given for the collective completion
of a group of tasks all blocked on select_statement
with open terminate_alternative
ensure that the collective completion can occur only when there are no
remaining active tasks that could call one of the tasks being collectively
12 The completion
of a task can occur due to any of the following:
the abort of the task.
Example of task
Global is access
Server; -- see 9.1
A, B : Server;
G : Global;
-- activation of A and B
Local is access
X : Global := new
Server; -- activation of X.all
L : Local := new
Server; -- activation of L.all
C : Server;
-- activation of C
G := X; -- both G and X designate the same task object
-- await termination of C and L.all (but not X.all)
-- await termination of A, B, and G.all
Wording Changes from Ada 83
Tasks that used to depend on library packages
in Ada 83, now depend on the (implicit) task_body
of the environment task (see 10.2
the environment task has to wait for them before performing library level
finalization and terminating the partition. In Ada 83 the requirement
to wait for tasks that depended on library packages was not as clear.
What was "collective termination"
is now "collective completion" resulting from selecting terminate_alternative
This is because finalization still occurs for such tasks, and this happens
after selecting the terminate_alternative
but before termination.
Wording Changes from Ada 95
Added missing wording that explained the master
of tasks that are neither object declarations nor allocators, such as
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe