!standard RM-D.3 (06) 95-11-01 AI95-00091/01 !class binding interpretation 95-09-29 !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 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 D.3(6) says: 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. [Emphasis added.] But Locking_Policy is a configuration pragma, and configuration pragmas do not "appear in" program units. What is the intent? !recommendation 95-09-29 (See wording.) !wording 95-09-29 In D.3(6), change "appears in" to "applies to". !discussion 95-09-29 The intent is as stated under "wording". !appendix 95-09-29 !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) !from Dan Lehman 95-09-08 !reference as: 95-5276.a Dan Lehman 95-9-8>> !discussion There is a conflict between the requirements of a configuration pragma and D.3's definition of pragma Locking_Policy. By 10.1(1,2) and 10.1.5(8), configuration pragmas cannot appear in a program unit (which must be in a compilation unit)--because, "they shall appear BEFORE the first compilation_unit of a compilation." But D.3(5) defines pragma Locking_Policy to be a configuration pragma, and D.3(6) states that "if no Locking_Policy pragma appears IN ANY OF THE PROGRAM UNITS comprising [sic] a partition," the intended effects of the pragam are implementation defined. Therefore, Locking_Policy is never other than an implementation-defined pragma! 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 ------- * **************************************************************** !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) !reference 95-5276.a Dan Lehman 95-9-8 !from Ted Baker 95-09-09 !reference as: 95-5277.a Ted Baker 95-9-9>> !discussion The conflict with Dan points out is a result of trying to make one global definition ("configuration pragma") serve many different purposes. 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 Baker **************************************************************** !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) !from Dan Lehman 95-09-08 !reference as: 95-5276.a Dan Lehman 95-9-8 !from Offer Pazy 95-09-09 !reference as: 95-5279.a Offer Pazy 95-9-9>> !discussion > There is a conflict between the requirements of a configuration > pragma and D.3's definition of pragma Locking_Policy. > . . . > 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 wasted...) Offer Pazy 31 Robinwood Ave. Boston, MA 02130 USA (617)522-5988 pazy@world.std.com **************************************************************** !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) !reference 95-5276.a Dan Lehman 95-9-8 !reference as: 95-5277.a Ted Baker 95-9-9 !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 .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 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 compilation. Offer Pazy 31 Robinwood Ave. Boston, MA 02130 USA (617)522-5988 pazy@world.std.com ****************************************************************