Annotated Ada Reference ManualLegal Information
Contents   Index   References   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: 
{AI95-00362-01} with Ada.Task_Identification;
package Ada.Asynchronous_Task_Control is
  pragma Preelaborate(Asynchronous_Task_Control);

  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

{AI95-00357-01} {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 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. 
  {AI95-00357-01} For any priority below System.Any_Priority'First, the task dispatching policy is FIFO_Within_Priorities. 
To be honest: This applies even if a Task_Dispatching_Policy specifies the policy for all of the priorities of the partition. 
Ramification: A task at the held priority never runs, so it is not necessary to implement FIFO_Within_Priorities for systems that have only one policy (such as EDF_Across_Priorities). 
{AI95-00357-01} The Hold operation sets the state of T to held. For a held task, the active priority is reevaluated as if the base priority of the task were the held priority: 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. 
{AI95-00357-01} The Continue operation resets the state of T to not-held; its T's active priority is then reevaluated as determined by the task dispatching policy associated with its base priority. 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. 
41  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.
42  The effect of calling Get_Priority and Set_Priority on a Held task is the same as on any other task.
43  Calling Hold on a held task or Continue on a non-held task has no effect.
44  The rules affecting queuing are derived from the above rules, in addition to the normal priority rules: 

Extensions to Ada 95

{AI95-00362-01} {extensions to Ada 95} Asynchronous_Task_Control is now Preelaborated, so it can be used in preelaborated units.

Wording Changes from Ada 95

{8652/0077} {AI95-00111-01} Corrigendum: Corrected to eliminate the use of the undefined term “accept body”.
{AI95-00357-01} The description of held tasks was changed to reflect that the calculation of active priorities depends on the dispatching policy of the base priority. Thus, the policy of the held priority was specified in order to avoid surprises (especially when using the EDF policy). 

Contents   Index   References   Search   Previous   Next 
Ada-Europe Sponsored by Ada-Europe