9.2 Task Execution - Task Activation
Dynamic Semantics
{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.
{
AI95-00416-01}
A task object (which represents one task) can be a part of a stand-alone
object, of an object created by 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 are
activated together. All tasks that are part or coextensions of a single
object that is not a stand-alone object are activated together.
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.
{
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,
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.
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.
{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.
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.
Discussion: Tasking_Error is raised only
once, even if two or more of the tasks being activated fail their activation.
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.
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.
5 An entry of a task can be called before
the task has been activated.
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.
7 A task can become completed during its
activation either because of an exception or because it is aborted (see
9.8).
Examples
Example of task
activation:
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
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.
This clause has been rewritten in an attempt
to improve presentation.
Wording Changes from Ada 95
{
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.