D.2.3 Preemptive Dispatching
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.
the delay does result in blocking, the task moves to the “delay
queue”, not to the ready queue.
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.
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.
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
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.
The amount of time that a task can be
preempted for processing on behalf of lower-priority tasks.
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).
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
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
We require that implementations allow this policy
and Ceiling_Locking together.
We explicitly defined FIFO_Within_Priorities to
be a task dispatching policy.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe