!standard D.3(10/3) 12-12-04 AI12-0051-1/01 !class binding interpretation 12-12-04 !status work item 12-12-04 !status received 12-09-24 !priority Low !difficulty Easy !subject The Priority aspect can be specified with Attach_Handler !summary The Priority aspect can be used in the protected type along with aspects Attach_Handler or Interrupt_Handler. !question Consider: protected Monitor is with Priority => System.Priority'Last; procedure Handler with Attach_Handler => 12; entry Wait; private Signaled : Boolean := False; end Monitor; What is the initial priority of Monitor? D.3(6.1/3) says that it is System.Priority'Last, while D.3(10/3) says that it is some implementation-defined value (because Interrupt_Priority isn't specified). Which is right? (D.3(6.1/3)). !recommendation (See summary.) !wording Modify D.3(10/3): If an Interrupt_Handler or Attach_Handler aspect pragma (see C.3.1) is specified for a protected subprogram of a protected type that does not have the {Priority or} Interrupt_Priority aspect specified, the initial priority of protected objects of that type is implementation defined, but in the range of the subtype System.Interrupt_Priority. !discussion It's clear that either D.3(6.1/3) or D.3(10/3) is wrong. C.3.1(11/3) specifies a runtime check for the priority value, which would be unnecessary if only Interrupt_Priority was allowed. Moreover, if an implementation allowed Priority and made the runtime check, it would be incompatible to make pragma Priority illegal (which would be especially annoying if the given priority was in the appropriate range). Liberalizing D.3(10/3) has no such compatibility problem, so that is the fix we make. !ACATS test An ACATS C-Test should be created to test these rules (and the runtime check of C.3.1(11/3)). !appendix From: Bob Duff Sent: Monday, September 24, 2012 8:46 AM Tristan Gingold found a bug in the RM related to pragma Priority. protected Monitor is pragma Priority (System.Priority'Last); procedure Handler; pragma Attach_Handler (Handler, 12); entry Wait; private Signaled : Boolean := False; end Monitor; D.3(6.1/3) says the priority is Priority'Last: 6.1/3 {AI95-00327-01} {AI05-0229-1} The expression specified for the Priority or Interrupt_Priority aspect (see D.1) is evaluated as part of the creation of the corresponding protected object and converted to the subtype System.Any_Priority or System.Interrupt_Priority, respectively. The value of the expression is the initial priority of the corresponding protected object. But D.3(10/3) contradicts that, saying the priority is some value in System.Interrupt_Priority: 10/3 * {AI95-00327-01} {AI05-0229-1} If an Interrupt_Handler or Attach_Handler aspect (see C.3.1) is specified for a protected subprogram of a protected type that does not have the Interrupt_Priority aspect specified, the initial priority of protected objects of that type is implementation defined, but in the range of the subtype System.Interrupt_Priority. It seems like pragma Priority should be illegal if Attach_Handler is given. Or vice versa. In GNAT, the above pragma Priority is ignored, which is not very friendly. **************************************************************** From: Bob Duff Sent: Monday, September 24, 2012 8:57 AM > It seems like pragma Priority should be illegal if Attach_Handler is > given. Or vice versa. In which case C.3.1(11/3) would be unnecessary: 11/3 {AI95-00434-01} {AI05-0229-1} If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object that contains a protected procedure for which either the Attach_Handler aspect is specified or the Interrupt_Handler aspect is True, a check is made that the initial ceiling priority of the object is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised. Hmm. So it currently works to have both pragma Priority and Attach_Handler, so long as the priority is in interrupt range, which is checked at run time. So making the pragma Priority illegal would be incompatible. So we should fix D.3(10/3): ...that does not have the Interrupt or Interrupt_Priority aspect specified... **************************************************************** From: Tuillo Vardanega Sent: Monday, September 24, 2012 9:43 AM To my reading, C.3.1(11/3) requires the priority to be in the interrupt range, which is what D.3(10/3) also requires. So the problem seems to be with D.3(6.1/3), which is more liberal. ****************************************************************