D.2.4 Non-Preemptive Dispatching
1/2
{
AI95-00298-01}
[This clause defines a non-preemptive task dispatching
policy.] Static Semantics
2/2
Legality Rules
3/2
{
AI95-00355-01}
Non_Preemptive_FIFO_Within_Priorities shall not
be specified as the policy_identifier
of pragma Priority_Specific_Dispatching (see
D.2.2).3.a/2
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
4/2
{
AI95-00298-01}
When Non_Preemptive_FIFO_Within_Priorities is in
effect, modifications to the ready queues occur only as follows:5/2
- {AI95-00298-01}
When a blocked task becomes ready, it is added
at the tail of the ready queue for its active priority.
6/2
- 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.
7/2
- 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.
8/2
- 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.
8.a/2
Ramification: If
the delay does result in blocking, the task moves to the “delay
queue”, not to the ready queue.
9/2
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
10/2
{
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. 10.a/2
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
11/2
{
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
11.a/2
Sponsored by Ada-Europe