!standard D.5 (10) 04-11-08 AI95-00188-02/01 !class binding interpretation 04-11-08 !status work item 04-11-08 !status received 04-11-08 !priority Medium !difficulty Medium !subject Setting a task base priority is immediate !summary Setting a task's base priority becomes immediate, but the reordering of entry queues is allowed to be deferred. !question Must the setting of a task base priority happen "immediately" on a monoprocessor, in analogy with the requirements for preemptive abort? !recommendation Rather than allow an implementation to change the priority of a task "as soon as practical", the change is required to be immediate, but the reordering of entry queues is allowed to be deferred. This deals with the problem of entry queues and layered run-time kernels, but requires an immediate change if the task is on a ready queue or the delay queue. !wording Replace D.5(10) with Setting the task's base priority to the new value takes place immediately unless the task is performing a protected action in which case it is postponed until the protected action is completed. Add new paragraph to D.4(15) under Implementation Permissions: Implementations are allowed to defer the reordering of entry queues following a change of base priority of a task blocked on the entry call if it is not practical to reorder the queue immediately. AARM Note: The reordering should occur as soon as the blocked task can itself perform the reinsertion into the entry queue. !discussion The questioner was expecting a response along the lines of: There seems no reason that the timing requirements for changing a task's priority and aborting a task on a single processor should differ significantly. Hence, the term "immediately" should be used in the definition of when a task's base priority is changed on a single processor, once the task is outside a protected action. In particular, there seems no justification to allow real-time implementations to defer the change of base priority until the task wakes up on its own at its old priority, because the purpose of raising its priority may very well be to have the target task "immediately" preempt some intermediate priority task. However, there is some justification for the difference. The difference is that "completing" a construct is not the same as "exiting" the construct, and priority change is closer to exiting, since it has a big nasty side-effect -- namely, removal and re-insertion of queued entry calls -- that may require waiting for the caller-task to execute. This makes if difficult to implement on a multi-threaded (multi-lock) run-time kernel, or on a layered (non-Ada) kernel. From an implementation point of view, we can have some other task mark a given task as having "completed" a construct, but to actually execute the finalization code and leave the construct we need to wait for the affected task to run. By analogy, here we can change the priority of a task, but if we want the task's entry calls to be repositioned, we have to wait until the task can be scheduled. The abort statement is defined in the core language and the IRTAW was concerned that a 'valid' implementation could postpone the effect of abort indefinitely - hence the use of "immediate" in the Real-Time Annex. By contrast, the dynamic priorities package is a Annex D facility and hence it was be assumed that the implementation does the right thing, and that "as soon as practical" is strong enough. However there is evidence that implementations not only postpone the change of priority for a task on an entry queue but also for those on ready queues and the delay queue. This does undermine the fundamental purpose of changing another task's priority; and hence some tightening of the language definition is justified. !appendix The discussion in the other alternative of this AI illustrates why entry queues are problematic. ****************************************************************