Contents Index Search Related Documents Previous Next
D.4 Entry Queuing Policies
1/1
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
2
The form of
a pragma Queuing_Policy is as follows:
3
pragma Queuing_Policy(
policy_identifier);
Legality Rules
4
The
policy_identifier
shall be either FIFO_Queuing, Priority_Queuing or an implementation-defined
identifier.
Post-Compilation Rules
5
A Queuing_Policy
pragma is a configuration pragma.
Dynamic Semantics
6
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.
7/2
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.
8
The Priority_Queuing
policy is defined as follows:
9
- 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).
10/1
- 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.
11
- 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.
12
- 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.
13
- If the expiration time of two or more
open delay_alternatives is the same
and no other accept_alternatives
are open, the sequence_of_statements
of the delay_alternative that is
first in textual order in the selective_accept
is executed.
14
- 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
15/2
Implementations are allowed to define other
queuing policies, but need not support more than one queuing policy per
partition.
15.1/2
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
16
The implementation should use names that end
with “_Queuing” for implementation-defined queuing policies.
Contents Index Search Related Documents Previous Next Legal