Contents   Index   Search   Previous   Next

D.11 Asynchronous Task Control

   [This clause introduces a language-defined package to do asynchronous suspend/resume on tasks. It uses a conceptual held priority value to represent the task's held state.]

Static Semantics

   The following language-defined library package exists:
with Ada.Task_Identification;
package Ada.Asynchronous_Task_Control is
  procedure Hold(T : in Ada.Task_Identification.Task_ID);
  procedure Continue(T : in Ada.Task_Identification.Task_ID);
  function Is_Held(T : Ada.Task_Identification.Task_ID)
   return Boolean;
end Ada.Asynchronous_Task_Control;

Dynamic Semantics

   {task state (held) [partial]} {held priority} {idle task} After the Hold operation has been applied to a task, the task becomes held. For each processor there is a conceptual idle task, which is always ready. The base priority of the idle task is below System.Any_Priority'First. The held priority is a constant of the type integer whose value is below the base priority of the idle task.
Discussion: The held state should not be confused with the blocked state as defined in 9.2; the task is still ready.
   The Hold operation sets the state of T to held. For a held task: the task's own base priority does not constitute an inheritance source (see D.1), and the value of the held priority is defined to be such a source instead.
Ramification: For example, if T is currently inheriting priorities from other sources (e.g. it is executing in a protected action), its active priority does not change, and it continues to execute until it leaves the protected action.
   The Continue operation resets the state of T to not-held; T's active priority is then reevaluated as described in D.1. [This time, T's base priority is taken into account.]
   The Is_Held function returns True if and only if T is in the held state.
Discussion: Note that the state of T can be changed immediately after Is_Held returns.
   As part of these operations, a check is made that the task identified by T is not terminated. {Tasking_Error (raised by failure of run-time check)} Tasking_Error is raised if the check fails. {Program_Error (raised by failure of run-time check)} Program_Error is raised if the value of T is Null_Task_ID.

Erroneous Execution

   {erroneous execution (cause) [partial]} If any operation in this package is called with a parameter T that specifies a task object that no longer exists, the execution of the program is erroneous.

Implementation Permissions

    An implementation need not support Asynchronous_Task_Control if it is infeasible to support it in the target environment.
Reason: A direct implementation of the Asynchronous_Task_Control semantics using priorities is not necessarily efficient enough. Thus, we envision implementations that use some other mechanism to set the ``held'' state. If there is no other such mechanism, support for Asynchronous_Task_Control might be infeasible, because an implementation in terms of priority would require one idle task per processor. On some systems, programs are not supposed to know how many processors are available, so creating enough idle tasks would be problematic.
33  It is a consequence of the priority rules that held tasks cannot be dispatched on any processor in a partition (unless they are inheriting priorities) since their priorities are defined to be below the priority of any idle task.
34  The effect of calling Get_Priority and Set_Priority on a Held task is the same as on any other task.
35  Calling Hold on a held task or Continue on a non-held task has no effect.
36  The rules affecting queuing are derived from the above rules, in addition to the normal priority rules:

Contents   Index   Search   Previous   Next   Legal