D.4 Entry Queuing Policies
This clause specifies a mechanism
for a user to choose an entry
queuing policy. It also defines
two such policies. Other policies are implementation defined.
Syntax
The form of a
pragma
Queuing_Policy is as follows:
Legality Rules
The
policy_identifier
shall be either FIFO_Queuing, Priority_Queuing or an implementation-defined
identifier.
Post-Compilation Rules
A Queuing_Policy
pragma is a configuration pragma.
Dynamic Semantics
A
queuing policy governs
the order in which tasks are queued for entry service, and the order
in which different entry queues are considered for service. The queuing
policy is specified by a Queuing_Policy pragma.
Two queuing policies, FIFO_Queuing and Priority_Queuing,
are language defined. If no Queuing_Policy pragma applies to any of the
program units comprising the partition, the queuing policy for that partition
is FIFO_Queuing. The rules for this policy are specified in
9.5.3
and
9.7.1.
The Priority_Queuing
policy is defined as follows:
The calls to an entry (including
a member of an entry family) are queued in an order consistent with the
priorities of the calls. The
priority of an entry call is initialized
from the active priority of the calling task at the time the call is
made, but can change later. Within the same priority, the order is consistent
with the calling (or requeuing, or priority setting) time (that is, a
FIFO order).
After a call is first queued, changes to the active
priority of a task do not affect the priority of the call, unless the
base priority of the task is set while the task is blocked on an entry
call.
When the base priority of a task is set (see
D.5),
if the task is blocked on an entry call, and the call is queued, the
priority of the call is updated to the new active priority of the calling
task. This causes the call to be removed from and then reinserted in
the queue at the new active priority.
When more than one
condition
of an
entry_barrier
of a protected object becomes True, and more than one of the respective
queues is nonempty, the call with the highest priority is selected. If
more than one such call has the same priority, the call that is queued
on the entry whose declaration is first in textual order in the
protected_definition
is selected. For members of the same entry family, the one with the lower
family index is selected.
When more than one alternative of a
selective_accept
is open and has queued calls, an alternative whose queue has the highest-priority
call at its head is selected. If two or more open alternatives have equal-priority
queued calls, then a call on the entry in the
accept_alternative
that is first in textual order in the
selective_accept
is selected.
Implementation Permissions
Implementations are allowed to define other queuing
policies, but need not support more than one queuing policy per partition.
Implementations are allowed to defer the reordering
of entry queues following a change of base priority of a task blocked
on the entry call if it is not practical to reorder the queue immediately.
Implementation Advice
The implementation should use names that end with
“_Queuing” for implementation-defined queuing policies.