Version 1.8 of 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:
- 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.
by:
- 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.
!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