D.2.3 Preemptive Dispatching
This clause defines a preemptive task dispatching
policy.
Static Semantics
The
policy_identifier
FIFO_Within_Priorities is a task dispatching policy.
Dynamic Semantics
When FIFO_Within_Priorities is in effect, modifications
to the ready queues occur only as follows:
When a blocked task becomes ready, it is added
at the tail of the ready queue for its active priority.
When the active priority of a ready task that is
not running changes, or the setting of its base priority takes effect,
the task is removed from the ready queue for its old active priority
and is added at the tail of the ready queue for its new active priority,
except in the case where the active priority is lowered due to the loss
of inherited priority, in which case the task is added at the head of
the ready queue for its new active priority.
When the setting of the base priority of a running
task takes effect, the task is added to the tail of the ready queue for
its active priority.
When a task executes a
delay_statement
that does not result in blocking, it is added to the tail of the ready
queue for its active priority.
Each of the
events specified above is a task dispatching point (see
D.2.1).
A task dispatching point occurs for the currently
running task of a processor whenever there is a nonempty ready queue
for that processor with a higher priority than the priority of the running
task. The currently running task is said to be
preempted and it
is added at the head of the ready queue for its active priority.
Implementation Requirements
An implementation shall allow, for a single partition,
both the task dispatching policy to be specified as FIFO_Within_Priorities
and also the locking policy (see
D.3) to be
specified as Ceiling_Locking.
Documentation Requirements
Priority
inversion is the duration for which a task remains at the head of
the highest priority nonempty ready queue while the processor executes
a lower priority task. The implementation shall document:
The maximum priority inversion a user task can
experience due to activity of the implementation (on behalf of lower
priority tasks), and
whether execution of a task can be preempted by
the implementation processing of delay expirations for lower priority
tasks, and if so, for how long.
14 If the active priority of a running
task is lowered due to loss of inherited priority (as it is on completion
of a protected operation) and there is a ready task of the same active
priority that is not running, the running task continues to run (provided
that there is no higher priority task).
15 Setting the base priority of a ready
task causes the task to move to the tail of the queue for its active
priority, regardless of whether the active priority of the task actually
changes.