D.2.3 Preemptive Dispatching
Static Semantics
Dynamic Semantics
{
AI95-00321-01}
When FIFO_Within_Priorities is in effect, modifications to the ready
queues occur only as follows:
{
AI95-00321-01}
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.
Ramification: If the delay does result
in blocking, the task moves to the “delay queue”, not to
the ready queue.
{
AI95-00321-01}
Each of the events specified
above is a task dispatching point (see
D.2.1).
{
AI95-00321-01}
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
{
AI95-00333-01}
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.
Reason: This is the preferred combination
of the FIFO_Within_Priorities policy with a locking policy, and we want
that combination to be portable.
Documentation Requirements
{
AI95-00321-01}
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
Documentation Requirement: The maximum
priority inversion a user task can experience from the implementation.
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.
Documentation Requirement: The amount
of time that a task can be preempted for processing on behalf of lower-priority
tasks.
NOTE 1 {
AI95-00321-01}
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).
NOTE 2 {
AI95-00321-01}
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.
Wording Changes from Ada 95
{
AI95-00321-01}
This subclause is new; it mainly consists of text that was found in
D.2.1
and
D.2.2 in Ada 95. This was separated out
so the definition of additional policies was easier.
{
AI95-00333-01}
We require that implementations allow this policy and Ceiling_Locking
together.
{
AI95-00355-01}
We explicitly defined FIFO_Within_Priorities to be a task dispatching
policy.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
