Version 1.1 of ais/ai-00321.txt
!standard D.02.01 (04) 03-01-07 AI95-00321/01
!standard D.02.01 (06)
!standard D.02.01 (08)
!standard D.02.02 (03)
!standard D.02.02 (07)
!standard D.02.02 (13)
!class amendment 03-01-07
!status work item 03-01-07
!status received 03-01-07
!subject Definition of dispatching policies
New wording is proposed for paragraphs within D.2.1 and D.2.2 to remove a
problem and to enable further dispatching policies to be added to Annex D.
As it is currently worded the general model for dispatching (as defined in
D.2.1) does not define the required behaviour. Specifically the current
running task is not considered as a candidate for the next running task as it
is not on a ready queue. Rewording of D.2.1 (6) is necessary. In addition,
some of the specific rules necessary for defining the FIFO_Within_Priority
policy in D.2.2 are, unnecessarily, given in Section D.2.1 where only the
general dispatching policy should be defined. This makes it difficult to
specify other policies within the annex (for example, non-preemptive
Some wording changes are proposed for the annex. Those deal with the problems
defined above. Wording changes are also proposed to facilitate the definition
of other dispatching policies in the Annex.
Remove 'the completion of an accept_statement (see 9.5.2),' from D.2.1(4).
Replace D.2.1(6) last sentence with:
If the current running task has a priority greater or equal to the task at the
head of the highest priority non-empty ready queue it continues to be the
running task; otherwise the task at the head of the highest priority non-empty
ready queue is selected, this task is then removed from all ready queues to
which it belongs.
Replace D.2.1(8) with:
A task reaches a task dispatching point whenever the task dispatching policy
requires a running task to go back to a ready queue.
Replace D.2.2(3) with:
The policy-identifier shall be FIFO_Within_Priority, an alternative policy from
D.14 or an implementation-defined identifier.
Replace D.2.2 (7):
When FIFO_Within_Priorities is in effect, modifications to the ready queues
occur only as follows.
Add after D.2.2(13):
A new running task is selected whenever there is a non-empty ready queue with a
higher priority than the priority of the running task. This is also a task
dispatching point for this policy.
The inclusion of 'completion of an accept_statement (see 9.5.2),' in
D.2.1(4) does not seem to be justified. It is not the only case in which
a task changes priority and/or unblocks another task. It has not been
moved to D.2.2 as the overriding rule of higher priority task always
preempting covers this and all similar cases.
An example does not seem valuable for this proposal.
Questions? Ask the ACAA Technical Agent