CVS difference for ais/ai-00092.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00092.txt

--- ais/ai-00092.txt	1998/09/30 00:17:15	1.1
+++ ais/ai-00092.txt	1999/07/21 03:10:57	1.2
@@ -1,5 +1,6 @@
-!standard RM-D.11  (05)                               96-07-23  AI95-00092/05
+!standard RM-D.11  (05)                               99-07-20  AI95-00092/06
 !class binding interpretation 95-09-29
+!status Corrigendum 2000 99-05-25
 !status WG9 approved 96-12-07
 !status ARG approved 9-0-0  96-06-17
 !status work item 95-11-01
@@ -8,13 +9,13 @@
 !difficulty Hard
 !subject Priority changes due to Set_Priority and Hold are not transitive
 
-!summary 95-09-29
+!summary
 
 If Set_Priority or Hold is called on a task, other tasks that are
 currently inheriting priority from the first task do not have their
 active priorities modified.
 
-!question 95-09-29
+!question
 
 D.1(21-22) says:
 
@@ -24,14 +25,14 @@
    22  During rendezvous, the task accepting the entry call inherits the
        active priority of the caller (see 9.5.3).
 
-But this implies that if Set_Priority or Hold is called on a task, 
+But this implies that if Set_Priority or Hold is called on a task,
 other tasks that are currently inheriting priority from the first
 task, would have to have their active priorities modified.
 Is this asynchronous priority inheritance the intent?  (No.)
 
-!recommendation 95-09-29
+!recommendation
 
-!wording 95-09-29
+!wording
 
 Modify D.1(21-22) as follows:
 
@@ -46,7 +47,7 @@
 way that it doesn't change during rendezvous -- it can only change when
 the call is still queued.
 
-!discussion 95-09-29
+!discussion
 
 Note: This AI subsumes AI95-00090.
 
@@ -85,7 +86,7 @@
     In this alternative, if Set_Priority is applied to a task, then
     other tasks that are currently inheriting priority from the first
     task do not have their active priorities modified.
-    
+
     Alternative 2: Asynchronous priority inheritance is not required,
     but an implementation may do it.  In this alternative, when
     Set_Priority is applied to a task, it is implementation-defined
@@ -149,9 +150,34 @@
 Given the advantages of implementation uniformity, Alternative 1 is
 chosen.  Implementations that wish to support asynchronous priority
 inheritance must do so via a non-standard policy.
+
+!corrigendum D.01(21)
 
-!appendix 96-04-04
+@drepl
+@xindent<During activation, a task being activated inherits the active
+priority of the its activator (see 9.2).>
+@dby
+@xindent<During activation, a task being activated inherits the active
+priority that its activator (see 9.2) had at the time the
+activation was initiated.>
+
+!corrigendum D.01(22)
+
+@drepl
+@xindent<During rendezvous, the task accepting the entry call inherits the
+active priority of the caller (see 9.5.3).>
+@dby
+@xindent<During rendezvous, the task accepting the entry call inherits the
+priority of the entry call (see 9.5.3 and D.4).>
+
+!ACATS test
+
+A test is needed to check that the priority doesn't change when it shouldn't
+(using Set_Priority and/or Hold). Check that existing test CXDB005 does not
+violate this ruling.
 
+!appendix
+
 !section RM-D.1(22)
 !subject Priority inheritance in rendezvous from async select
 !reference RM95-D.1(22)
@@ -168,18 +194,18 @@
 
   During rendezvous, the task accepting the entry call inherits the
   active priority of the caller while the caller is blocked on
-  the entry call; for a call due to an asynchronous select, it inherits 
-  the priority that was the active priority of the caller at the time 
+  the entry call; for a call due to an asynchronous select, it inherits
+  the priority that was the active priority of the caller at the time
   the entry call was issued.
 
 This could be simplified to say simply "the task accepting the
 entry call inherits the priority of the entry call" which is
-defined in D.4(9), but the priority of a "call" does not 
+defined in D.4(9), but the priority of a "call" does not
 change when the caller's priority changes due to
 priority inheritance.   We presumably want indirect priority
 inheritance to work, whereas there was a conscious decision to
-not require priority inheritance to cause entry queue reordering, 
-so that priority inheritance could be implemented more efficiently 
+not require priority inheritance to cause entry queue reordering,
+so that priority inheritance could be implemented more efficiently
 (and "implicitly" using some kind of chained ready-queue structure) --
 see the discussion of dynamic priorities in the Ada 95 Rationale.
 
@@ -223,7 +249,7 @@
    to complete, the active priority of the accepting task is not affected.
 
 This is true if the active priority of the acceptor was originally higher
-than that of the caller.  But per D.1(20,22), if the active priority of 
+than that of the caller.  But per D.1(20,22), if the active priority of
 the acceptor was originally lower than that of the caller, then the acceptor's
 active priority should drop to that old value when the caller is held,
 since the caller's active priority has effectively dropped to minus
@@ -249,7 +275,7 @@
 |    to complete, the active priority of the accepting task is not affected.
 
 | This is true if the active priority of the acceptor was originally higher
-| than that of the caller.  But per D.1(20,22), if the active priority of 
+| than that of the caller.  But per D.1(20,22), if the active priority of
 | the acceptor was originally lower than that of the caller, then the acceptor's
 | active priority should drop to that old value when the caller is held,
 | since the caller's active priority has effectively dropped to minus
@@ -325,38 +351,38 @@
 !discussion
 
 > Tucker said:
-> 
+>
 > | The note in paragraph D.11(17) seems wrong.  It says:
-> 
+>
 > |    If a task becomes held while waiting (as a caller) for a rendezvous
 > |    to complete, the active priority of the accepting task is not affected.
-> 
+>
 > | This is true if the active priority of the acceptor was originally higher
-> | than that of the caller.  But per D.1(20,22), if the active priority of 
+> | than that of the caller.  But per D.1(20,22), if the active priority of
 > | the acceptor was originally lower than that of the caller, then the acceptor's
 > | active priority should drop to that old value when the caller is held,
 > | since the caller's active priority has effectively dropped to minus
 > | infinity.
-> 
+>
 > We intentionally did not require adjustment of active priority,
 > because we wanted to allow flexibility for efficient
 > implementation of the low-level tasking operations.
 > ...
 
-I don't find this "flexibility" in the RM, except in 
+I don't find this "flexibility" in the RM, except in
 note D.11(17), which does not imply flexibility, but rather
 implies that you must *not* propagate the change in active priority
 to the acceptor.  Can you cite any non-note paragraphs which indicate this
 "flexibility" or which specify exactly what should happen
 when an entry caller in rendezvous is held?  D.1(20,22) seems to
 indicate that the active priority of the caller is relevant throughout
-the rendezvous.  We all seem to agree that this means the priority of 
+the rendezvous.  We all seem to agree that this means the priority of
 the "call" when the call was from an async-select, but I don't find any
 basis for deciding what to do in the case of a synchronous call
 from a task that is then held.
 
 In the case where both the caller and the acceptor are held, then
-I would expect that both tasks would stop running immediately, 
+I would expect that both tasks would stop running immediately,
 whereas if only one of them is held, then the rendezvous would complete
 before the held task stops.  This implies that when a task is
 held, it's base priority no longer contributes to itself nor
@@ -366,7 +392,7 @@
 > To preserve the intent of these operations, I suggest that if there
 > is any change/interpretation it be toward allowing a wider range
 > of efficienct implementations, e.g.
-> 
+>
 > | It is implementation defined whetehr when a task becomes held
 > | while waiting (as a caller) for a rendezvous to complete, the
 > | active priority of the accepting task is affected.
@@ -379,8 +405,8 @@
 a bit weak in the case where a rendezvous is already involved ;-).
 
 Finally, for an acceptor, it is clear that you have to recompute the
-active priority for the rendezvous when the acceptor is held, so it 
-doesn't seem very surprising that if the caller is held, then the 
+active priority for the rendezvous when the acceptor is held, so it
+doesn't seem very surprising that if the caller is held, then the
 priority of the rendezvous also needs to be recomputed.
 
 > --Ted Baker
@@ -398,75 +424,75 @@
 !reference as: 95-5287.a Offer Pazy 95-9-13>>
 !discussion
 
-Please look at the rationale (D.1.2) for a discussion of the issues for when 
-to have priority inheritance and where not to.  Quite early in the process, 
-we have decided not to have transitive priority inheritance for many reasons 
-mostly because of implementation difficulties and 
-"not-essential-when-we-have-protected-objects" argumnets. 
-
-Having a task inherit the priority of the caller *after* the rendezvous has 
-started really falls under transitive priority inheritance since the event 
-that may cause the priority change is asynchronous to teh executing task. 
-(I'm a bit lazy to repeat all the issues, they are sumarized quite nicely in 
+Please look at the rationale (D.1.2) for a discussion of the issues for when
+to have priority inheritance and where not to.  Quite early in the process,
+we have decided not to have transitive priority inheritance for many reasons
+mostly because of implementation difficulties and
+"not-essential-when-we-have-protected-objects" argumnets.
+
+Having a task inherit the priority of the caller *after* the rendezvous has
+started really falls under transitive priority inheritance since the event
+that may cause the priority change is asynchronous to teh executing task.
+(I'm a bit lazy to repeat all the issues, they are sumarized quite nicely in
 the rationale's section mentioned above).
 
-That my view with respect to our design principles, and therefore I think 
-that the note in D.11(17) is correct and should stay this way. (Note also 
-that D.4(11) talk only about the case when the calling task in on the queue, 
+That my view with respect to our design principles, and therefore I think
+that the note in D.11(17) is correct and should stay this way. (Note also
+that D.4(11) talk only about the case when the calling task in on the queue,
 not when the rendesvous/entry body has started.)
 
-I agree that we have a problem with the word "during" in D.1(22), but it is 
-clear to me that if something has to change, this is the rule that needs to 
-change.  Doing otherwise, will have *very heavy* implememetation cost and is 
+I agree that we have a problem with the word "during" in D.1(22), but it is
+clear to me that if something has to change, this is the rule that needs to
+change.  Doing otherwise, will have *very heavy* implememetation cost and is
 a big deviation from the Ada 83 rules (and is not needed).
 
-> We all seem to agree that this means the priority of 
+> We all seem to agree that this means the priority of
 > the "call" when the call was from an async-select,
 
-Not all of us... If you stick with D.1 (22) I don't see any basis (or need 
-or benefit) to distinguish between the two cases. But I really think that we 
-shoudl try very hard not to require implementations to support 
-transitive-priority-inheritance.  This will be unfortunate, since it will 
-require vendors to do a lot of work which we have not intented to require, 
+Not all of us... If you stick with D.1 (22) I don't see any basis (or need
+or benefit) to distinguish between the two cases. But I really think that we
+shoudl try very hard not to require implementations to support
+transitive-priority-inheritance.  This will be unfortunate, since it will
+require vendors to do a lot of work which we have not intented to require,
 just because of a "typo".
 
 > In the case where both the caller and the acceptor are held, then
-> I would expect that both tasks would stop running immediately, 
+> I would expect that both tasks would stop running immediately,
 > whereas if only one of them is held, then the rendezvous would complete
-> before the held task stops. 
+> before the held task stops.
 
 
-This is a ramification of the current rules.  I hope you don't suggest a new 
+This is a ramification of the current rules.  I hope you don't suggest a new
 rule here.
 
 > > | It is implementation defined whetehr when a task becomes held
 > > | while waiting (as a caller) for a rendezvous to complete, the
 > > | active priority of the accepting task is affected.
-> 
+>
 > Seems reasonable, but I don't find any sign of this in the
 > current RM, other than the note in D.11(17), which doesn't imply
-> any flexibility.  
+> any flexibility.
 
-I don't know based on what you see it is impl-defined, and I really don't 
-like it to be impl-defined here. I think it's not a useful way-out.  We have 
+I don't know based on what you see it is impl-defined, and I really don't
+like it to be impl-defined here. I think it's not a useful way-out.  We have
 a contradiction, but there is no hint of impl-definedness here.
 
 > Finally, for an acceptor, it is clear that you have to recompute the
-> active priority for the rendezvous when the acceptor is held, so it 
-> doesn't seem very surprising that if the caller is held, then the 
+> active priority for the rendezvous when the acceptor is held, so it
+> doesn't seem very surprising that if the caller is held, then the
 > priority of the rendezvous also needs to be recomputed.
 
-It's a big difference.  For the acceptor: You change its base (or make it 
-held) and then you recompute its active priority.  If you chnage the base 
-(or make held) of the caller, then you have to recompute the active priority 
+It's a big difference.  For the acceptor: You change its base (or make it
+held) and then you recompute its active priority.  If you chnage the base
+(or make held) of the caller, then you have to recompute the active priority
  of another task (the acceptor) which makes it an asynchronous change.
 
 
-Finally, note that all this discussion has nothing to do with the related 
-discussion of queue reordering as a result of changing the base priority 
-since in neither PO queue no task entry queue, the priorities of the tasks 
-on the queue do not serve as a source of PI. Furthermore, for PO's the 
-ceiling is static so it does not matter.  In summary, this is another 
+Finally, note that all this discussion has nothing to do with the related
+discussion of queue reordering as a result of changing the base priority
+since in neither PO queue no task entry queue, the priorities of the tasks
+on the queue do not serve as a source of PI. Furthermore, for PO's the
+ceiling is static so it does not matter.  In summary, this is another
 argument all together.
 
 Offer Pazy
@@ -510,7 +536,7 @@
 
 | Seems reasonable, but I don't find any sign of this in the
 | current RM, other than the note in D.11(17), which doesn't imply
-| any flexibility.  
+| any flexibility.
 
 Right.  The current RM seems pretty clear, and it does not say
 what either you or I would prefer, in our present enlighted states.
@@ -530,8 +556,8 @@
 much extra work would be involved.)
 
 | Finally, for an acceptor, it is clear that you have to recompute the
-| active priority for the rendezvous when the acceptor is held, so it 
-| doesn't seem very surprising that if the caller is held, then the 
+| active priority for the rendezvous when the acceptor is held, so it
+| doesn't seem very surprising that if the caller is held, then the
 | priority of the rendezvous also needs to be recomputed.
 
 I don't see why you would want to recompute the active priority of
@@ -610,7 +636,7 @@
 If you do change the priority of the acceptor, than you may need to follow
 the chain of rendezvous and maybe change the priority of other acceptors.
 This represents an asynchronous recomputation of an active priority, again,
-something that we have consciously avoided. There may be an arbitrary number 
+something that we have consciously avoided. There may be an arbitrary number
 of queues which you will have to visit (locking them all).
 
 Also, We have given the same treatment (and hopefully a consistent one) to
@@ -618,12 +644,12 @@
 freely with the same set of rules.  If you change rendezvous, you will have
 to do the same here.
 
-You may also run into logical races: Assume the accept body declares a task. 
-For the accept body to complete, the task needs to finish. The priority of 
-the 
-task can be determined based on the activator's (the acceptor in this case) 
-only at the time of activation.  If the acceptor priority changes later, 
-there 
+You may also run into logical races: Assume the accept body declares a task.
+For the accept body to complete, the task needs to finish. The priority of
+the
+task can be determined based on the activator's (the acceptor in this case)
+only at the time of activation.  If the acceptor priority changes later,
+there
 is no way to "rush" the inside task.
 
 Finally, the Held state is defined in terms of dynamic priorities and
@@ -654,15 +680,15 @@
 in (22) *and* (21).  Please look also at AI-00090 which, in my opinion, is
 the same issue (or closely related to it)
 
-Leaving the word "during" for the sync call case will necessitate the same 
-kind of impl difficulty, inconsistency with no added user value. 
+Leaving the word "during" for the sync call case will necessitate the same
+kind of impl difficulty, inconsistency with no added user value.
 
 The discussion section says:
 
-> We want indirect priority inheritance to work, 
+> We want indirect priority inheritance to work,
 
-I don't know what "indirect priorty inheritance" means since it is not 
-defined anywhere.  But I would guess that quite on the contrary, we do *not* 
+I don't know what "indirect priorty inheritance" means since it is not
+defined anywhere.  But I would guess that quite on the contrary, we do *not*
 want to require such inheritance.
 
 Tucker says:
@@ -671,8 +697,8 @@
 >
 >   During rendezvous, the task accepting the entry call inherits the
 >   active priority of the caller while the caller is blocked on
->   the entry call; for a call due to an asynchronous select, it inherits 
->   the priority that was the active priority of the caller at the time 
+>   the entry call; for a call due to an asynchronous select, it inherits
+>   the priority that was the active priority of the caller at the time
 >   the entry call was issued.
 
 
@@ -739,9 +765,9 @@
 
 I believe there are three separate issues:
 
-   a) Whether or not dynamic priority changes should apply transitively 
-      via priority inheritance; that is, when you change the priority 
-      of a task using Set_Priority (or via Hold), is the priority of 
+   a) Whether or not dynamic priority changes should apply transitively
+      via priority inheritance; that is, when you change the priority
+      of a task using Set_Priority (or via Hold), is the priority of
       any other task that is inheriting priority from this task
       indirectly affected at the same time.
 
@@ -756,14 +782,14 @@
 
 The answers to (b) and (c) are given quite clearly in RM95 D.4(10,11).
 The answer to (c) is that the position in an entry queue never changes for
-an asynchronous call, and to (b) is that the position only changes for a 
+an asynchronous call, and to (b) is that the position only changes for a
 synchronous call due to a direct setting of the base priority of the caller.
 
 The answer to (a) is more difficult to determine from the RM.  Based
 on assurances from Offer, Ted, and Mike Kamrad, it seems clear to me
 now that there was no intent for dynamic priority changes to "ripple"
 through many tasks via transitive application of priority inheritance.
-However, paragraphs D.1(20..24) are clearly written in terms of 
+However, paragraphs D.1(20..24) are clearly written in terms of
 continuous and ongoing transitive priority inheritance.  Furthermore,
 Ted acknowledges that there are efficient implementations of priority
 inheritance that are inherently transitive.
@@ -773,19 +799,19 @@
 that we make it implementation-defined (that is, it must be documented)
 whether changes to the priority of a (synchronous) caller on a task entry
 have any effect on the acceptor's priority, and similarly whether
-changes to the priority of an activator have any effect on the 
+changes to the priority of an activator have any effect on the
 tasks being activated, if these changes happen after the rendezvous
-begins, or after activation begins.  
+begins, or after activation begins.
 
-The rationale for this recommendation is that, presumably, 
+The rationale for this recommendation is that, presumably,
 transitive priority inheritance can have at least a modest benefit
 via reducing priority inversion, and we should not actively
 discourage implementations from providing this capability.  However, by
-not requiring such transitive priority inheritance, we allow the 
+not requiring such transitive priority inheritance, we allow the
 implementor (presumably in consultation with the relevant customers)
 to tradeoff implementation burden and efficiency against the advantages
 of reduced priority inversion.  It would certainly be unfortunate
-if the most efficient implementation of priority inheritance turns out 
+if the most efficient implementation of priority inheritance turns out
 to be inherently transitive, and we disallow the use of this approach
 because we fear it is too inefficient.
 
@@ -806,7 +832,7 @@
 !discussion
 
 It seems highly desirable that Hold and Set_Priority have consistent
-effects.  Holding a task should be considered essentially equivalent to 
+effects.  Holding a task should be considered essentially equivalent to
 dropping its base priority to sub-idle, from the point of view
 of priority inheritance, etc.   We describe it as removing the
 base priority as a source of inheritance because we don't want to
@@ -814,12 +840,12 @@
 Continue to restore the original state without having the Hold-er have
 to remember the old base priority.
 
-This AI is stating the case for not requiring asynchronous 
+This AI is stating the case for not requiring asynchronous
 transitive priority inheritance.  However, as I argued in my
 comment on AI95-00090, I believe it is better at this point to
 allow the choice between transitive and nontranstive priority
-inheritance to be implementation-defined.  There are efficient 
-approaches to priority inheritance that are inherently transitive, 
+inheritance to be implementation-defined.  There are efficient
+approaches to priority inheritance that are inherently transitive,
 and it would be unfortunate if we effectively outlaw their use.
 It also may be that existing kernels already implement one or the
 other approach to priority inheritance, and it seems desirable to
@@ -829,7 +855,7 @@
 on priority inheritance being *not* asynchronously transitive, given
 the numerous race conditions which could mask this distinction.
 Hence, there seems no serious portability issue in allowing
-priority inheritance to be asynchronously transitive. 
+priority inheritance to be asynchronously transitive.
 
 Note that the reverse is not true -- it does seem possible for
 an application to become dependent on an implementation supporting
@@ -872,7 +898,7 @@
 
 I didn't mean to be talking about protected object locking at all.
 
-As far as I can see, there is no defined policy pragma relating to 
+As far as I can see, there is no defined policy pragma relating to
 priority inheritance for rendezvous and activation.
 
 > This would be really dangerous.  These are semantically two
@@ -927,8 +953,8 @@
 
 | ... I believe it is better at this point to
 | allow the choice between transitive and nontranstive priority
-| inheritance to be implementation-defined.  There are efficient 
-| approaches to priority inheritance that are inherently transitive, 
+| inheritance to be implementation-defined.  There are efficient
+| approaches to priority inheritance that are inherently transitive,
 | and it would be unfortunate if we effectively outlaw their use.
 | It also may be that existing kernels already implement one or the
 | other approach to priority inheritance, and it seems desirable to
@@ -938,7 +964,7 @@
 | on priority inheritance being *not* asynchronously transitive, given
 | the numerous race conditions which could mask this distinction.
 | Hence, there seems no serious portability issue in allowing
-| priority inheritance to be asynchronously transitive. 
+| priority inheritance to be asynchronously transitive.
 
 | Note that the reverse is not true -- it does seem possible for
 | an application to become dependent on an implementation supporting
@@ -973,9 +999,9 @@
 about priority inheritance via task entry calls and task
 activation.
 
-|    a) Whether or not dynamic priority changes should apply transitively 
-|       via priority inheritance; that is, when you change the priority 
-|       of a task using Set_Priority (or via Hold), is the priority of 
+|    a) Whether or not dynamic priority changes should apply transitively
+|       via priority inheritance; that is, when you change the priority
+|       of a task using Set_Priority (or via Hold), is the priority of
 |       any other task that is inheriting priority from this task
 |       indirectly affected at the same time.
 
@@ -1047,7 +1073,7 @@
 
 | The rationale for this recommendation is that, presumably,
 | transitive priority inheritance can have at least a modest
-  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^? 
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^?
 | benefit via reducing priority inversion, and we should not
 | actively discourage implementations from providing this
 | capability.  However, by not requiring such transitive priority
@@ -1076,7 +1102,7 @@
 
 Yes.
 
-| As far as I can see, there is no defined policy pragma relating to 
+| As far as I can see, there is no defined policy pragma relating to
 | priority inheritance for rendezvous and activation.
 
 Right.  However, ARM D.1 (29) allows an implementation to provide

Questions? Ask the ACAA Technical Agent