9.2 Task Execution - Task Activation
Dynamic Semantics
1
{execution (task) 
[partial]} The execution of a task of a given 
task type consists of the execution of the corresponding 
task_body. 
{execution (task_body) [partial]} 
{task (execution)} 
{activation (of a 
task)} {task 
(activation)} The initial part of this 
execution is called the 
activation of the task; it consists of 
the elaboration of the 
declarative_part of 
the 
task_body. 
{activation 
failure} Should an exception be propagated 
by the elaboration of its 
declarative_part, 
the activation of the task is defined to have 
failed, and it becomes 
a completed task.
 
2/2
{
AI95-00416-01} 
A task object (which represents one task) can be 
a 
part of a stand-alone object, of an object created by created 
either as part of the elaboration of an object_declaration 
occurring immediately within some declarative region, or as part of the 
evaluation of an 
allocator, 
or of an anonymous object of a limited type, or a coextension of one 
of these. All tasks
 that are part or coextensions 
of any of the stand-alone objects created by the elaboration of 
object_declarations
 (or generic_associations of formal objects 
of mode in) of a single declarative region
 (including subcomponents of the declared objects) are activated 
together. 
All tasks that are part or coextensions 
of a single object that is not a stand-alone object are activated together. Similarly, 
all tasks created by the evaluation of a single allocator 
are activated together. The activation of a task is associated with the 
innermost allocator or object_declaration 
that is responsible for its creation.  
2.a
Discussion: The initialization of an 
object_declaration or allocator 
can indirectly include the creation of other objects that contain tasks. 
For example, the default expression for a subcomponent of an object created 
by an allocator might call a function that 
evaluates a completely different allocator. 
Tasks created by the two allocators are not activated together. 
3/2
{
AI95-00416-01} 
For 
the tasks
 created 
by the elaboration of object_declarations 
of a given declarative region, the activations are initiated within the 
context of the 
handled_sequence_of_statements 
(and its associated 
exception_handlers if 
any — see 
11.2), just prior to executing 
the statements of the 
handled_sequence_of_statements _sequence. 
[For a package without an explicit body or an explicit 
handled_sequence_of_statements, 
an implicit body or an implicit 
null_statement 
is assumed, as defined in 
7.2.] 
 
3.a
Ramification: If Tasking_Error is raised, 
it can be handled by handlers of the handled_sequence_of_statements. 
4/2
{
AI95-00416-01} 
For tasks 
that are part or coextensions of a single 
object that is not a stand-alone object, activations are initiated after 
completing any initialization of the outermost object enclosing these 
tasks, prior to performing any other operation on the outermost object. 
In particular, for tasks that are part or coextensions of the object 
created by the evaluation of an 
allocator, 
the activations are initiated as the last step of evaluating the 
allocator, 
after completing any initialization for the object 
created by the allocator, and prior 
to returning the new access value.
 For tasks that 
are part or coextensions of an object that is the result of a function 
call, the activations are not initiated until after the function returns. 
4.a/2
Discussion: {
AI95-00416-01} 
The intent is that “temporary” objects 
with task parts (or coextensions) are treated similarly to an object 
created by an allocator. The “whole” object is initialized, 
and then all of the task parts (including the coextensions) are activated 
together. Each such “whole” object has its own task activation 
sequence, involving the activating task being suspended until all the 
new tasks complete their activation.  
5
{activator (of a 
task)} {blocked 
(waiting for activations to complete) [partial]} The 
task that created the new tasks and initiated their activations (the 
activator) is blocked until all of these activations complete 
(successfully or not). 
{Tasking_Error 
(raised by failure of run-time check)} Once 
all of these activations are complete, if the activation of any of the 
tasks has failed [(due to the propagation of an exception)], Tasking_Error 
is raised in the activator, at the place at which it initiated the activations. 
Otherwise, the activator proceeds with its execution normally. Any tasks 
that are aborted prior to completing their activation are ignored when 
determining whether to raise Tasking_Error. 
 
5.a
Ramification: Note that a task created 
by an allocator does not necessarily depend 
on its activator; in such a case the activator's termination can precede 
the termination of the newly created task. 
5.b
Discussion: Tasking_Error is raised only 
once, even if two or more of the tasks being activated fail their activation. 
5.c/2
To be honest: {
AI95-00265-01} 
The pragma Partition_Elaboration_Policy (see H.6) 
can be used to defer task activation to a later point, thus changing 
many of these rules.  
6
Should the task that created the new tasks never 
reach the point where it would initiate the activations (due to an abort 
or the raising of an exception), the newly created tasks become terminated 
and are never activated. 
7
5  An entry of a task can be called before 
the task has been activated.
8
6  If several tasks are activated together, 
the execution of any of these tasks need not await the end of the activation 
of the other tasks.
9
7  A task can become completed during its 
activation either because of an exception or because it is aborted (see 
9.8).
 
Examples
10
Example of task 
activation: 
11
procedure P is
   A, B : Server;    --  elaborate the task objects A, B
   C    : Server;    --  elaborate the task object C
begin
   --  the tasks A, B, C are activated together before the first statement
   ...
end;
Wording Changes from Ada 83
11.a
We have replaced the term suspended with 
blocked, since we didn't want to consider a task blocked when 
it was simply competing for execution resources. "Suspended" 
is sometimes used more generally to refer to tasks that are not actually 
running on some processor, due to the lack of resources.
11.b
This clause has been rewritten in an attempt 
to improve presentation. 
Wording Changes from Ada 95
11.c/2
{
AI95-00416-01} 
Adjusted the wording for activating tasks to handle 
the case of anonymous function return objects. This is critical; we don't 
want to be waiting for the tasks in a return object when we exit the 
function normally.