Go to the first, previous, next, last section, table of contents.

9.3 Task Dependence - Termination of Tasks

Dynamic Semantics

  1. Each task (other than an environment task -- See section 10.2 Program Execution, depends on one or more masters, See section 7.6.1 Completion and Finalization, as follows:
    1. If the task is created by the evaluation of an allocator for a given access type, it depends on each master that includes the elaboration of the declaration of the ultimate ancestor of the given access type.
    2. If the task is created by the elaboration of an object_declaration, it depends on each master that includes this elaboration.

  1. 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.
  2. 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 section 7.6.1 Completion and Finalization. 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.
  3. Completion of a task (and the corresponding task_body) can occur when the task is blocked at a select_statement with an an open terminate_alternative, See section 9.7.1 Selective Accept, the open terminate_alternative is selected if and only if the following conditions are satisfied:
    1. The task depends on some completed master;
    2. Each task that depends on the master considered is either already terminated or similarly blocked at a select_statement with an open terminate_alternative.

  1. 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.


  2. (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 type.
  3. (9) An object_renaming_declaration defines a new view of an existing entity and hence creates no further dependence.
  4. (10) The rules given for the collective completion of a group of tasks all blocked on select_statements with open terminate_alternatives ensure that the collective completion can occur only when there are no remaining active tasks that could call one of the tasks being collectively completed.
  5. (11) If two or more tasks are blocked on select_statements with open terminate_alternatives, and become completed collectively, their finalization actions proceed concurrently.
  6. (12) The completion of a task can occur due to any of the following:
    1. the raising of an exception during the elaboration of the declarative_part of the corresponding task_body;
    2. the completion of the handled_sequence_of_statements of the corresponding task_body;
    3. the selection of an open terminate_alternative of a select_statement in the corresponding task_body;
    4. the abort of the task.


  1. Example of task dependence:
  2. declare
       type Global is access Server; --  See section 9.1 Task Units and Task Objects
       A, B : Server;
       G    : Global;
       --  activation of A and B
          type Local is access Server;
          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
       end;  --  await termination of C and L.all (but not X.all)
    end;  --  await termination of A, B, and G.all

Go to the first, previous, next, last section, table of contents.