Contents Index Previous Next
D.5 Dynamic Priorities
1
[This clause specifies how the base priority of
a task can be modified or queried at run time.]
Static Semantics
2
The following language-defined
library package exists:
3
with System;
with Ada.Task_Identification; -- See C.7.1
package Ada.Dynamic_Priorities is
4
procedure Set_Priority(Priority : in System.Any_Priority;
T : in Ada.Task_Identification.Task_ID :=
Ada.Task_Identification.Current_Task);
5
function Get_Priority (T : Ada.Task_Identification.Task_ID :=
Ada.Task_Identification.Current_Task)
return System.Any_Priority;
6
end Ada.Dynamic_Priorities;
Dynamic Semantics
7
The procedure Set_Priority sets the base priority
of the specified task to the specified Priority value. Set_Priority has
no effect if the task is terminated.
8
The function Get_Priority returns T's current
base priority.
{Tasking_Error (raised by failure of
run-time check)} Tasking_Error is raised
if the task is terminated.
8.a
Reason: There is no harm
in setting the priority of a terminated task. A previous version of Ada
9X made this a run-time error. However, there is little difference between
setting the priority of a terminated task, and setting the priority of
a task that is about to terminate very soon; neither case should be an
error. Furthermore, the run-time check is not necessarily feasible to
implement on all systems, since priority changes might be deferred due
to inter-processor communication overhead, so the error might not be
detected until after Set_Priority has returned.
8.b
However, we wish to allow implementations
to avoid storing ``extra'' information about terminated tasks. Therefore,
we make Get_Priority of a terminated task raise an exception; the implementation
need not continue to store the priority of a task that has terminated.
9
{Program_Error (raised by failure
of run-time check)} Program_Error is raised
by Set_Priority and Get_Priority if T is equal to Null_Task_ID.
10
Setting the task's base priority to
the new value takes place as soon as is practical but not while the task is
performing a protected action. This setting occurs no later then the next abort
completion point of the task T (see
9.8).
10.a
Implementation Note: When
Set_Priority is called by a task T1 to set the priority of T2, if T2
is blocked, waiting on an entry call queued on a protected object, the
entry queue needs to be reordered. Since T1 might have a priority that
is higher than the ceiling of the protected object, T1 cannot, in general,
do the reordering. One way to implement this is to wake T2 up and have
T2 do the work. This is similar to the disentangling of queues that needs
to happen when a high-priority task aborts a lower-priority task, which
might have a call queued on a protected object with a low ceiling.
10.b
Reason:
A previous version of Ada 9X made it a run-time error for a high-priority
task to set the priority of a lower-priority task that has a queued call
on a protected object with a low ceiling. This was changed because:
10.c
- The check was not feasible to implement on all systems,
since priority changes might be deferred due to inter-processor communication
overhead. The calling task would continue to execute without finding
out whether the operation succeeded or not.
10.d
- The run-time check would tend to cause intermittent system
failures -- how is the caller supposed to know whether the other task
happens to have a queued call at any given time? Consider for example
an interrupt that needs to trigger a priority change in some task. The
interrupt handler could not safely call Set_Priority without knowing
exactly what the other task is doing, or without severely restricting
the ceilings used in the system. If the interrupt handler wants to hand
the job off to a third task whose job is to call Set_Priority, this won't
help, because one would normally want the third task to have high priority.
Bounded (Run-Time) Errors
11
{bounded error (cause) [partial]}
If a task is blocked on a protected entry call, and
the call is queued, it is a bounded error to raise its base priority
above the ceiling priority of the corresponding protected object. When
an entry call is cancelled, it is a bounded error if the priority of
the calling task is higher than the ceiling priority of the corresponding
protected object.
{Program_Error (raised by failure
of run-time check)} In either of these
cases, either Program_Error is raised in the task that called the entry,
or its priority is temporarily lowered, or both, or neither.
11.a
Ramification: Note that
the error is ``blamed'' on the task that did the entry call, not the
task that called Set_Priority. This seems to make sense for the case
of a task blocked on a call, since if the Set_Priority had happened a
little bit sooner, before the task queued a call, the entry-calling task
would get the error. In the other case, there is no reason not to raise
the priority of a task that is executing in an abortable_part,
so long as its priority is lowered before it gets to the end and needs
to cancel the call. The priority might need to be lowered to allow it
to remove the call from the entry queue, in order to avoid violating
the ceiling. This seems relatively harmless, since there is an error,
and the task is about to start raising an exception anyway.
Erroneous Execution
12
{erroneous execution (cause)
[partial]} If any subprogram 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.
12.a
Ramification: Note that
this rule overrides the above rule saying that Program_Error is raised
on Get_Priority of a terminated task. If the task object still exists,
and the task is terminated, Get_Priority raises Program_Error. However,
if the task object no longer exists, calling Get_Priority causes erroneous
execution.
Metrics
13
The implementation
shall document the following metric:
14
- The execution time of a call to Set_Priority, for the nonpreempting
case, in processor clock cycles. This is measured for a call that modifies
the priority of a ready task that is not running (which cannot be the
calling one), where the new base priority of the affected task is lower
than the active priority of the calling task, and the affected task is
not on any entry queue and is not executing a protected operation.
15
22 Setting a task's base
priority affects task dispatching. First, it can change the task's active
priority. Second, under the standard task dispatching policy it always
causes the task to move to the tail of the ready queue corresponding
to its active priority, even if the new base priority is unchanged.
16
23 Under the priority queuing policy,
setting a task's base priority has an effect on a queued entry call if the task
is blocked waiting for the call. That is, setting the base priority of a task
causes the priority of a queued entry call from that task to be updated and
the call to be removed and then reinserted in the entry queue at the new priority
(see D.4), unless the call originated from the triggering_statement
of an asynchronous_select.
17
24 The effect of two or more
Set_Priority calls executed in parallel on the same task is defined as
executing these calls in some serial order.
17.a
18
25 The rule for when Tasking_Error
is raised for Set_Priority or Get_Priority is different from the rule for when
Tasking_Error is raised on an entry call (see 9.5.3).
In particular, setting or querying the priority of a completed or an abnormal
task is allowed, so long as the task is not yet terminated.
19
26 Changing the priorities
of a set of tasks can be performed by a series of calls to Set_Priority
for each task separately. For this to work reliably, it should be done
within a protected operation that has high enough ceiling priority to
guarantee that the operation completes without being preempted by any
of the affected tasks.
Contents Index Previous Next Legal