Version 1.1 of ais/ai-00445.txt

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

!standard D.5.2(1)          06-01-10 AI95-00445/01
!class Amendment 06-01-10
!status Amendment 200Y 06-01-10
!comment This will be included in draft 16 of the Amendment.
!status work item 06-01-10
!status received 06-01-05
!subject Dynamic ceilings and interrupt handlers
!summary
The introduction of dynamic ceilings for protected objects requires a check to be made for those protected objects that are used as interrupt handlers. This check is missing from the current version of the language definition. Wording to cover this check is provided.
!problem
In Ada95 a check is made on the ceiling priority of a protected object, which is initialized with either an Attach_Handler or Interrupt_Handler pragma, to ensure that it is in the appropriate System.Interrupt_Priority range. In Ada 2005 this is no longer sufficient as the ceiling priority of the protected object can change during execution - via an assignment to 'Priority.
!proposal
Raise Program_Error at the point of the assignment to 'Priority if the value to be assigned is outside the range of System.Interrupt_Priority and the associated protected object has either an Attach_Handler or Interrupt_Handler pragma. Wording similar to C.3.1(11) is used.
!wording
Add a new paragraph to the dynamic semantics of D.5.2 as defined by AI-327:
If the locking policy Ceiling_Locking is in effect then for protected objects with either an Attach_Handler or Interrupt_Handler pragma applying to one of its procedures, a check is made that the value to be assigned to 'Priority is in the range System.Interrupt_Priority. If the check fails, Program_Error is raised.
!corrigendum D.5.2(01)
!comment Dummy paragraph to force a conflict. The real change is recorded in
!comment the conflict text.
@dinsc This clause specifies how the priority of a protected object can be modified or queried at run time.
!ACATS test
!appendix

From: Erhard Ploedereder
Sent: Saturday, November 26, 2005 10:36 AM

D.3 (13) says that "when a task calls a protected operation, <a ceiling
check happens>"

What happens when a protected operation attached as an interrupt handler
calls a protected operation (P_E, erroneous, blocking possible, sh...) ?

This wasn't a problem until ceiling priorities became dynamic, since
Attach_Handler made the ceiling check upon attaching the handler.

D.5.2 (or somewhere else) should answer this question.

Please fix or else make this the first(?) AI against Ada05. :-)

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

From: Alan Burns
Sent: Monday, November 28, 2005  5:12 AM

It looks like a sensible fix would be to add a further paragraph to dynamic
semantics of D.5.2 to say if  P has pragmas Interrupt_Handler or Attach_Handler
then an attempt to assign 'Priority to a value outside the range of
Interrupt_Priority will cause P_E to be raised at the point of the assignment.

I would make this a rule regardless of locking policy

There is an argument that a PO with pragma Interrupt_Priority should also be
restricted to never have a priority outside the range of Interrrupt_Priority.

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

From: Erhard Ploedereder
Sent: Tuesday, November 29, 2005  1:15 PM

Definitely.
C.3.1(11) provides the template for the wording.

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

From: Pascal Leroy
Sent: Wednesday, November 30, 2005  5:31 AM

...
> There is an argument that a PO with pragma Interrupt_Priority should
> also be restricted to never have a priority outside the range of
> Interrrupt_Priority.

What about the other direction?  Does it make sense for a protected object
without these pragmas to be assigned a 'Priority in Interrupt_Priority?
Just curious.

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

From: Erhard Ploedereder
Sent: Wednesday, November 30, 2005  8:00 PM

> There is an argument that a PO with pragma Interrupt_Priority should
> also be restricted to never have a priority outside the range of
> Interrrupt_Priority.

YES. (I just reread the manual and was completely amazed that this pragma
accepts any priority value, even though it may be below the interrupt
range.)

> What about the other direction?  Does it make sense for a protected object
> without these pragmas to be assigned a 'Priority in Interrupt_Priority?
> Just curious.

It does make sense. For tasks, it's allowed and the argument is that it
should be possible to thereby have tasks block (up to some level of)
interrupts.  Analogously, one could use the ceiling priority of POs to do
that, too.

Most importantly, if any task in the interrupt priority range wants to access
a shared resource, that resource better have a high enough ceiling priority.
Otherwise these tasks would have real problems to communicate safely.

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

From: Alan Burns
Sent: Thursday, December  1, 2005  2:39 AM

>What about the other direction?  Does it make sense for a protected object
>without these pragmas to be assigned a 'Priority in Interrupt_Priority?
>Just curious.

I think this is OK, and matches what a task can do. One may have a style of
programming that does not use the pragma at all but uses a 'master' task to
call in and set all ceilings (and then all task priorities).

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

From: Tucker Taft
Sent: Thursday, December  1, 2005  6:56 AM

The Interrupt_Priority pragma allows any priority,
whereas plain old Priority allows only non-interrupt-level
priorities.  We felt there was more danger in
setting a priority into the interrupt level by mistake,
than setting it too low by mistake.  The ceiling
check will catch you if you set it too low.  Nothing
will warn you if by mistake you set it into the
interrupt range.  At least that was the thinking
during the 9X process...

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

From: Alan Burns
Sent: Thursday, January  5, 2006  4:20 AM

Erhard noticed a hole in the semantics for dynamic ceilings. The following
fixes this problem. I'm not sure if this is an AI or some other construct.
[This is version /01 of this AI - ED]
I would hope that the UK would formally submit it to WG9, but Randy
and others will no doubt want to modify the wording, and John B may
know the correct form for submitting this 'correction'.

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

Questions? Ask the ACAA Technical Agent