Version 1.8 of ai12s/ai12-0051-1.txt

Unformatted version of ai12s/ai12-0051-1.txt version 1.8
Other versions for file ai12s/ai12-0051-1.txt

!standard D.3(10/3)          13-05-08 AI12-0051-1/03
!class binding interpretation 12-12-04
!status Corrigendum 1-2012 12-12-27
!status WG9 Approved 13-06-14
!status ARG Approved 10-0-0 12-12-06
!status work item 12-12-04
!status received 12-09-24
!priority Low
!difficulty Easy
!subject The Priority aspect can be specified when Attach_Handler is specified
!summary
The Priority aspect can specify the priority of an interrupt handler.
!question
Consider:
protected Monitor is with Priority => System.Priority'Last;
procedure Handler with Attach_Handler => ...;
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 (see C.3.1) is specified for a protected subprogram of a protected type that does not have {either} 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 specifying the Priority aspect 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.
!corrigendum D.3(10/3)
Replace the paragraph:
by:
!ACATS test
An ACATS C-Test should be created to test these rules (and the runtime check of C.3.1(11/3)).
!ASIS
No ASIS impact.
!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.

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

Questions? Ask the ACAA Technical Agent