Version 1.1 of ais/ai-00091.txt

Unformatted version of ais/ai-00091.txt version 1.1
Other versions for file ais/ai-00091.txt

!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

!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

****************************************************************

Questions? Ask the ACAA Technical Agent