!standard D.5 (10) 98-04-09 AI95-00188/01 !class binding interpretation 97-08-19 !status work item 98-04-02 !status received 97-08-19 !priority Medium !difficulty Medium !subject The definition of setting a task base priority is too vague !summary 98-04-09 Setting a task's base priority takes place immediately on a monoprocessor, and as soon as practical on a multiprocessor, except not while the task is performing a protected action. On a multiprocessor, the setting occurs no later than the next abort completion point of the task T. !question 98-04-09 Must the setting of a task base priority happen "immediately" on a monoprocessor, in analogy with the requirements for preemptive abort? (Yes.) !recommendation 98-04-09 The wording for setting a task's base priority should be analogous to the wording given for preemptive abort. In particular, on a single processor, the task's base priority is set immediately at the first point that is outside the execution of a protected action. On a multiprocessor, the setting should happen as soon as practical once a task is outside a protected action. Implementations should document what conditions cause the base priority change to be delayed on a multiprocessor. !wording 98-04-09 !discussion 98-04-09 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. !appendix 97-08-19 !section D.5(10) !subject The definition of setting a task base priority is too vague !reference RM95-D.5(10) !reference RM95-D.6(2) !from Offer Pazy 97-04-19 !reference 1997-15745.b Offer Pazy 1997-4-19>> !discussion At the IRTWA8, it was noted that the use of "as soon as practical" is unnecessarily vague. I believe that the words was chosen with multiprocessors in mind. However, a similar problem exists for preemptive aborts (D.6(2)) and there the language is more precise. It was suggested to use similar words in D.5(10) in order to tighten the semantics for the single-processor case. (Note that even if the multi-processor case is not considered, the single-processor case when running on top of a virtual processor layer such as threads, should be kept in mind.) **************************************************************** From: Ted Baker[SMTP:baker@dad.cs.fsu.edu] !reference AI95-00188/01 !reference RM95-D.6(2) !from Ted Baker !discussion (I apologize for not doing my action-item from the previous ARG meeting, but taking a 180-degree turn from what we agreed upon in St. Louis is too much punishment, if that is the intention! :-) The proposed binding resolution would break the GNAT tasking implementation in a fundamental way, that I don't know how to fix. Furthermore, it is contrary to the intent of the original Ada'9X design as I understood it when I was working on this annex. | Setting a task's base priority takes place immediately on a monoprocessor, This is a direct contradiction of the ARM language. D5 (10) was extensively debated, and the loosenss of "as soon as is practical" was entirely intentional. | 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... | 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... 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. 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. [Note that the priority ceiling locking rules require that the calling task do its own queue reshuffling, or else we have no sensible way to treat the possibility of one of those operations raising Program_Error if it violates the priority ceiling. Note also that this his not an improbable thing, since users will typically give the task that is calling for a priority change a very high priority, so that it gets a chance to do its job!!] Offer and I argued extensively about this during the Ada'9X language design period. I wanted to have immediate priority changes, but not require entry-queue reordering. That is, I wanted the priority of a call to be frozen when it is made, and not change unless the call is explicitly requeued. Offer wanted to have queue reordering, but to make it implementable we had to allow the priority change to be deferred. If people feel strongly that the priority change should be immediate, then perhaps we can rework the compromise, by allowing the queue reordering to be deferred until the next time the task executes. That would require that we "interpret" D.4 (11) as possibly being delayed until the next time the task executes, at its new priority. --Ted Baker **************************************************************** From: Tucker Taft[SMTP:stt@inmet.com] Sent: Thursday, April 09, 1998 5:53 PM Subject: Re: AI-00188/1 Well one reason to send out these AIs is to get some response. I'm glad you have provided some rationale for the current wording of the manual. We should use that in the AI, whichever way we ultimately decide it should go. -Tuck ****************************************************************