CVS difference for ais/ai-00091.txt

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

--- ais/ai-00091.txt	1998/09/30 00:17:15	1.1
+++ ais/ai-00091.txt	1999/07/21 03:10:57	1.2
@@ -1,18 +1,19 @@
-!standard RM-D.3   (06)                               95-11-01  AI95-00091/01
+!standard RM-D.3   (06)                               99-07-20  AI95-00091/02
 !class binding interpretation 95-09-29
+!status Corrigendum 2000 99-05-25
 !status WG9 approved 95-06-14
 !status ARG approved 10-0-0  95-11-01
 !status received 95-09-29
 !subject Pragma Locking_Policy Cannot Be "In" a Program Unit
 
-!summary 95-09-29
+!summary
 
 If no Locking_Policy pragma applies to any of the program units
 comprising a partition, the locking policy for that partition, as well
 as the effect of specifying either a Priority or Interrupt_Priority
 pragma for a protected object, are implementation defined.
 
-!question 95-09-29
+!question
 
 D.3(6) says:
 
@@ -25,20 +26,37 @@
 But Locking_Policy is a configuration pragma, and configuration pragmas
 do not "appear in" program units.  What is the intent?
 
-!recommendation 95-09-29
+!recommendation
 
 (See wording.)
 
-!wording 95-09-29
+!wording
 
 In D.3(6), change "appears in" to "applies to".
 
-!discussion 95-09-29
+!discussion
 
 The intent is as stated under "wording".
+
+!corrigendum D.03(6)
+
+@dprepl
+If no Locking_Policy pragma appears in any of the program units comprising
+a partition, the locking policy for that partition, as well as the effect
+of specifying either a Priority or Interrupt_Priority pragma for a protected
+object, are implementation defined.
+@dby
+If no Locking_Policy pragma applies to any of the program units comprising
+a partition, the locking policy for that partition, as well as the effect
+of specifying either a Priority or Interrupt_Priority pragma for a protected
+object, are implementation defined.
+
+!ACATS test
 
-!appendix 95-09-29
+This wording correction is not testable by itself.
 
+!appendix
+
 !section RM-D.3(05)
 !subject Pragma Locking_Policy Cannot Be "In" a Program Unit
 !reference RM95-10.1(1,2), 10.1.5(8), D.3(5,6)
@@ -60,7 +78,7 @@
 
    I think that D.3(6) should instead say "if no Locking_Policy pragma
 applies to any of the program units comprised in a partition, ...".
- 
+
 ---Dan
 ------- *
 
@@ -77,7 +95,7 @@
 
 The conflict with Dan points out is a result of trying to make one
 global definition ("configuration pragma") serve many different
-purposes.  
+purposes.
 
 I DO NOT THINK that D.3(6) should instead say "if no
 Locking_Policy pragma applies to any of the program units
@@ -113,11 +131,11 @@
 >    I think that D.3(6) should instead say "if no Locking_Policy pragma
 > applies to any of the program units comprised in a partition, ...".
 
-Correct.  This is an unfortunate typo, and I hope I am not missing some 
-intended subtlety. Naturaly, I would prefer that a future interpretation 
-would follow the above suggestion and not declare all uses of the pragma 
-Locking_Policy as impl-defined. A large portion of the RT annex will then 
-become useless. (Which means that a "small amount" of previous work will be 
+Correct.  This is an unfortunate typo, and I hope I am not missing some
+intended subtlety. Naturaly, I would prefer that a future interpretation
+would follow the above suggestion and not declare all uses of the pragma
+Locking_Policy as impl-defined. A large portion of the RT annex will then
+become useless. (Which means that a "small amount" of previous work will be
 wasted...)
 
 Offer Pazy
@@ -137,34 +155,34 @@
 !from Offer Pazy 95-09-10
 !reference as: 95-5281.a Offer Pazy 95-9-10>>
 !discussion
- 
+
 > I DO NOT THINK that D.3(6) should instead say "if no
 > Locking_Policy pragma applies to any of the program units
 > comprised in a partition, ...".
-> 
+>
 > There is a reason for the wording in the RT annex, that predates
 > what finally came out for "configuration pragma".  The reason is
 > that correctness of a given package may depend on a particular
 > policy for locking, queueing, or dispatching.  There must be a way
 > for the writer of that package to specify this, so that:
-> 
+>
 >  (1) the correct policy will be chosen at link/bind time;
-> 
+>
 >  (2) if some other package requires a conflicting policy, this error
 >      will be caught at link/bind time.
 
-Ted is right with respect to the stated goal.  That was an important 
-consideration during the development (it is also mentioned in the rationale 
-towards the end of D.4 under the discusssion of the entry queuing conf 
+Ted is right with respect to the stated goal.  That was an important
+consideration during the development (it is also mentioned in the rationale
+towards the end of D.4 under the discusssion of the entry queuing conf
 .pragmas).
 
-However, I still think that there is no problem if the wording is changed as 
-suggested. The same kind of per-package control (#1 and #2 above) can be 
-achieved: instead of placing the pragma inside the package, place the 
-package in its own compilation unit and precede this comp-unit with the 
+However, I still think that there is no problem if the wording is changed as
+suggested. The same kind of per-package control (#1 and #2 above) can be
+achieved: instead of placing the pragma inside the package, place the
+package in its own compilation unit and precede this comp-unit with the
 conf. pragma.  The same kind of one-to-one association can thus be achieved.
-I don't think that it was ever desired to have a finer-grained control, i.e. 
-on nested packages or anything else that cannot be placed in its own 
+I don't think that it was ever desired to have a finer-grained control, i.e.
+on nested packages or anything else that cannot be placed in its own
 compilation.
 
 Offer Pazy

Questions? Ask the ACAA Technical Agent