Annotated Ada Reference ManualLegal Information
Table of Contents   Index   References   Search   Previous   Next 

 C.3.1 Protected Procedure Handlers


The form of a pragma Interrupt_Handler is as follows:
  pragma Interrupt_Handler(handler_name);
The form of a pragma Attach_Handler is as follows: 
  pragma Attach_Handler(handler_name, expression); 

Name Resolution Rules

For the Interrupt_Handler and Attach_Handler pragmas, the handler_name shall resolve to denote a protected procedure with a parameterless profile.
For the Attach_Handler pragma, the expected type for the expression is Interrupts.Interrupt_ID (see C.3.2). 

Legality Rules

{AI95-00434-01} The Attach_Handler pragma is only allowed immediately within the protected_definition where the corresponding subprogram is declared. The corresponding protected_type_declaration or single_protected_declaration shall be a library- level declaration. 
Discussion: In the case of a protected_type_declaration, an object_declaration of an object of that type need not be at library level. 
{AI95-00253-01} {AI95-00303-01} The Interrupt_Handler pragma is only allowed immediately within the a protected_definition where the corresponding subprogram is declared. The corresponding protected_type_declaration or single_protected_declaration shall be a library- level declaration. In addition, any object_declaration of such a type shall be a library level declaration. 

Dynamic Semantics

If the pragma Interrupt_Handler appears in a protected_definition, then the corresponding procedure can be attached dynamically, as a handler, to interrupts (see C.3.2). [Such procedures are allowed to be attached to multiple interrupts.]
{creation (of a protected object)} {initialization (of a protected object)} The expression in the Attach_Handler pragma [as evaluated at object creation time] specifies an interrupt. As part of the initialization of that object, if the Attach_Handler pragma is specified, the handler procedure is attached to the specified interrupt. {Reserved_Check [partial]} {check, language-defined (Reserved_Check)} A check is made that the corresponding interrupt is not reserved. {Program_Error (raised by failure of run-time check)} Program_Error is raised if the check fails, and the existing treatment for the interrupt is not affected.
 {AI95-00434-01} {initialization (of a protected object)} {Ceiling_Check [partial]} {check, language-defined (Ceiling_Check)} If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object for which that either an Attach_Handler or Interrupt_Handler pragma applies to one of its procedures, a check is made that the ceiling priority defined in the protected_definition is in the range of System.Interrupt_Priority. {Program_Error (raised by failure of run-time check)} If the check fails, Program_Error is raised.
 {8652/0068} {AI95-00121-01} {finalization (of a protected object)} When a protected object is finalized, for any of its procedures that are attached to interrupts, the handler is detached. If the handler was attached by a procedure in the Interrupts package or if no user handler was previously attached to the interrupt, the default treatment is restored. If an Attach_Handler pragma was used and the most recently attached handler for the same interrupt is the same as the one that was attached at the time the protected object was initialized Otherwise, [that is, if an Attach_Handler pragma was used], the previous handler is restored.
Discussion: {8652/0068} {AI95-00121-01} {AI95-00303-01} If all protected objects for interrupt handlers are declared at the library - level Since only library-level protected procedures can be attached as handlers using the Interrupts package, the finalization discussed above occurs only as part of the finalization of all library-level packages in a partition. However, objects of a protected type containing an Attach_Handler pragma need not be at the library level. Thus, an implementation needs to be able to restore handlers during the execution of the program. (An object with an Interrupt_Handler pragma also need not be at the library level, but such a handler cannot be attached to an interrupt using the Interrupts package.) 
When a handler is attached to an interrupt, the interrupt is blocked [(subject to the Implementation Permission in C.3)] during the execution of every protected action on the protected object containing the handler.

Erroneous Execution

{erroneous execution (cause) [partial]} If the Ceiling_Locking policy (see D.3) is in effect and an interrupt is delivered to a handler, and the interrupt hardware priority is higher than the ceiling priority of the corresponding protected object, the execution of the program is erroneous.
   {8652/0068} {AI95-00121-01} {erroneous execution (cause) [partial]} If the handlers for a given interrupt attached via pragma Attach_Handler are not attached and detached in a stack-like (LIFO) order, program execution is erroneous. In particular, when a protected object is finalized, the execution is erroneous if any of the procedures of the protected object are attached to interrupts via pragma Attach_Handler and the most recently attached handler for the same interrupt is not the same as the one that was attached at the time the protected object was initialized. 
Discussion: {8652/0068} {AI95-00121-01} This simplifies implementation of the Attach_Handler pragma by not requiring a check that the current handler is the same as the one attached by the initialization of a protected object.


The following metric shall be documented by the implementation: 
Implementation Note: The instruction sequence and interrupt handler used to measure interrupt handling overhead should be chosen so as to maximize the execution time cost due to cache misses. For example, if the processor has cache memory and the activity of an interrupt handler could invalidate the contents of cache memory, the handler should be written such that it invalidates all of the cache memory. 
Documentation Requirement: The metrics for interrupt handlers.

Implementation Permissions

When the pragmas Attach_Handler or Interrupt_Handler apply to a protected procedure, the implementation is allowed to impose implementation-defined restrictions on the corresponding protected_type_declaration and protected_body
Ramification: The restrictions may be on the constructs that are allowed within them, and on ordinary calls (i.e. not via interrupts) on protected operations in these protected objects. 
Implementation defined: Any restrictions on a protected procedure or its containing type when a pragma Attach_handler or Interrupt_Handler applies.
An implementation may use a different mechanism for invoking a protected procedure in response to a hardware interrupt than is used for a call to that protected procedure from a task. 
Discussion: This is despite the fact that the priority of an interrupt handler (see D.1) is modeled after a hardware task calling the handler. 
{notwithstanding} Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler pragmas are allowed to be used for other, implementation defined, forms of interrupt handlers. 
Ramification: For example, if an implementation wishes to allow interrupt handlers to have parameters, it is allowed to do so via these pragmas; it need not invent implementation-defined pragmas for the purpose. 
Implementation defined: Any other forms of interrupt handler supported by the Attach_Handler and Interrupt_Handler pragmas.

Implementation Advice

Whenever possible, the implementation should allow interrupt handlers to be called directly by the hardware. 
Implementation Advice: Interrupt handlers should be called directly by the hardware.
Whenever practical, the implementation should detect violations of any implementation-defined restrictions before run time.
Implementation Advice: Violations of any implementation-defined restrictions on interrupt handlers should be detected before run time.
4  The Attach_Handler pragma can provide static attachment of handlers to interrupts if the implementation supports preelaboration of protected objects. (See C.4.)
5  {AI95-00434-01} A The ceiling priority of a protected object that has a (protected) procedure one of its procedures is attached to an interrupt should have a ceiling priority be at least as high as the highest processor priority at which that interrupt will ever be delivered.
6  Protected procedures can also be attached dynamically to interrupts via operations declared in the predefined package Interrupts.
7  An example of a possible implementation-defined restriction is disallowing the use of the standard storage pools within the body of a protected procedure that is an interrupt handler.

Incompatibilities With Ada 95

{AI95-00253-01} {incompatibilities with Ada 95} Amendment Correction: Corrected the wording so that the rules for the use of Attach_Handler and Interrupt_Handler are identical. This means that uses of pragma Interrupt_Handler outside of the target protected type or single protected object are now illegal. 

Wording Changes from Ada 95

{8652/0068} {AI95-00121-01} Corrigendum: Clarified the meaning of “the previous handler” when finalizing protected objects containing interrupt handlers.
{AI95-00303-01} Dropped the requirement that an object of a type containing an Interrupt_Handler pragma must be declared at the library level. This was a generic contract model violation. This change is not an extension, as an attempt to attach such a handler with a routine in package Interrupts will fail an accessibility check anyway. Moreover, implementations can retain the rule as an implementation-defined restriction on the use of the type, as permitted by the Implementation Permissions above. 

Table of Contents   Index   References   Search   Previous   Next 
Ada-Europe Sponsored by Ada-Europe