D.2.4 Non-Preemptive Dispatching
{
AI95-00298-01}
[This clause defines a non-preemptive task dispatching policy.]
Static Semantics
Legality Rules
Reason: The non-preemptive nature of
this policy could cause the policies of higher priority tasks to malfunction,
missing deadlines and having unlimited priority inversion. That would
render the use of such policies impotent and misleading. As such, this
policy only makes sense for a complete system.
Dynamic Semantics
{
AI95-00298-01}
When Non_Preemptive_FIFO_Within_Priorities is in effect, modifications
to the ready queues occur only as follows:
{
AI95-00298-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.
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.
For this policy, a non-blocking
delay_statement
is the only non-blocking event that is a task dispatching point (see
D.2.1).
{task
dispatching point [partial]} {dispatching
point [partial]} Implementation Requirements
{
AI95-00333-01}
An implementation shall allow, for a single partition, both the task
dispatching policy to be specified as Non_Preemptive_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 Non_Preemptive_FIFO_Within_Priorities policy with a locking policy,
and we want that combination to be portable.
Implementation Permissions
{
AI95-00298-01}
Since implementations are allowed to round all ceiling priorities in
subrange System.Priority to System.Priority'Last (see
D.3),
an implementation may allow a task to execute within a protected object
without raising its active priority provided the associated protected
unit does not contain pragma Interrupt_Priority, Interrupt_Handler, or
Attach_Handler.
Extensions to Ada 95
Sponsored by Ada-Europe