CVS difference for ais/ai-00092.txt
--- ais/ai-00092.txt 2000/06/21 23:39:07 1.7
+++ ais/ai-00092.txt 2000/07/13 04:31:27 1.8
@@ -65,22 +65,22 @@
it is not clearly useful, given that priority inheritance is not
uniformly transitive in all cases.
-D.4(8-11) supports the above as the "intent":
+D.4(8-11) supports the above as the "intent". In particular, D.4(11):
- 11 When the base priority of a task is set (see D.5), if the task is
- blocked on an entry call, and the call is queued, the priority of
- the call is updated to the new active priority of the calling
- task. This causes the call to be removed from and then
- reinserted in the queue at the new active priority.
+ When the base priority of a task is set (see D.5), if the task is
+ blocked on an entry call, and the call is queued, the priority of
+ the call is updated to the new active priority of the calling
+ task. This causes the call to be removed from and then
+ reinserted in the queue at the new active priority.
If Set_Priority on an entry caller were really intended to affect the
active priority of a rendezvous-in-progress, then why would D.4(11) go
to the trouble to say "and the call is queued"? This intent is
also supported by the NOTE in D.11(17):
- 17 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.
+ 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.
There are two possible solutions:
@@ -119,10 +119,10 @@
When porting in the other direction, a working program could fail
because of a violation of the ceiling rule in D.3(13):
- 13 When a task calls a protected operation, a check is made that its
- active priority is not higher than the ceiling of the
- corresponding protected object; Program_Error is raised if this
- check fails.
+ When a task calls a protected operation, a check is made that its
+ active priority is not higher than the ceiling of the
+ corresponding protected object; Program_Error is raised if this
+ check fails.
In fact, Alternative 2 would allow an implementation to cause a
"retroactive" violation of D.3(13). Presumably, the implementation
@@ -130,9 +130,9 @@
asynchronous priority inheritance. Note that D.5(10) only talks about
the task being directly affected, not other inheritors:
- 10 Setting the task's base priority to the new value takes place as
- soon as is practical but not while the task is performing a
- protected action.
+ Setting the task's base priority to the new value takes place as
+ soon as is practical but not while the task is performing a
+ protected action.
Presumably, the implementation would extend this deferral of priority
changes to apply to the inheritors as well.
Questions? Ask the ACAA Technical Agent