CVS difference for 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