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.