Contents Index Search Previous Next
D.11 Asynchronous Task Control
1
[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
2
The following language-defined
library package exists:
3
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
4
{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.
4.a
Discussion: The held
state should not be confused with the blocked state as defined in 9.2;
the task is still ready.
5
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.
5.a
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.
6
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.]
7
The Is_Held function returns True if and only
if T is in the held state.
7.a
Discussion: Note that
the state of T can be changed immediately after Is_Held returns.
8
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
9
{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
10
An implementation need not support Asynchronous_Task_Control
if it is infeasible to support it in the target environment.
10.a
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.
11
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.
12
34 The effect of calling
Get_Priority and Set_Priority on a Held task is the same as on any other
task.
13
35 Calling Hold on a held
task or Continue on a non-held task has no effect.
14
36 The
rules affecting queuing are derived from the above rules, in addition
to the normal priority rules:
15
- When a held task
is on the ready queue, its priority is so low as to never reach the top
of the queue as long as there are other tasks on that queue.
16
- If a task is
executing in a protected action, inside a rendezvous, or is inheriting
priorities from other sources (e.g. when activated), it continues to
execute until it is no longer executing the corresponding construct.
17
- If a task becomes
held while waiting (as a caller) for a rendezvous to complete, the active
priority of the accepting task is not affected.
18/1
- {8652/0077}
If a task becomes held while waiting in a selective_accept,
and an entry call is issued to one of the open entries, the corresponding
accept_alternative
accept
body executes. When the rendezvous completes, the active priority
of the accepting task is lowered to the held priority (unless it is still
inheriting from other sources), and the task does not execute until another
Continue.
19
- The same holds
if the held task is the only task on a protected entry queue whose barrier
becomes open. The corresponding entry body executes.
Contents Index Search Previous Next Legal