Go to the first, previous, next, last section, table of contents.

C.3.1 Protected Procedure Handlers

Syntax

  1. The form of a pragma Interrupt_Handler is as follows: 
  2. pragma Interrupt_Handler(handler_name);
  3. The form of a pragma Attach_Handler is as follows: 
  4. pragma Attach_Handler(handler_name, expression);

    Name Resolution Rules

  5. For the Interrupt_Handler and Attach_Handler pragmas, the handler_name shall resolve to denote a protected procedure with a parameterless profile.
  6. For the Attach_Handler pragma, the expected type for the expression is Interrupts.Interrupt_ID, See section C.3.2 The Package Interrupts.

    Legality Rules

  7. 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.
  8. The Interrupt_Handler pragma is only allowed immediately within a protected_definition. The corresponding protected_type_declaration shall be a library level declaration. In addition, any object_declaration of such a type shall be a library level declaration.

    Dynamic Semantics

  9. If the pragma Interrupt_Handler appears in a protected_definition, then the corresponding procedure can be attached dynamically, as a handler, to interrupts, See section C.3.2 The Package Interrupts. Such procedures are allowed to be attached to multiple interrupts.
  10. 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. A check is made that the corresponding interrupt is not reserved. Program_Error is raised if the check fails, and the existing treatment for the interrupt is not affected.
  11. If the Ceiling_Locking policy, See section D.3 Priority Ceiling Locking is in effect then upon the initialization of a protected object 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. If the check fails, Program_Error is raised.
  12. 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. Otherwise, that is, if an Attach_Handler pragma was used, the previous handler is restored.
  13. When a handler is attached to an interrupt, the interrupt is blocked (subject to the Implementation Permission in See section C.3 Interrupt Support, during the execution of every protected action on the protected object containing the handler.

    Erroneous Execution

  14. If the Ceiling_Locking policy, See section D.3 Priority Ceiling Locking, 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.

    Metrics

  15. The following metric shall be documented by the implementation:
    1. The worst case overhead for an interrupt handler that is a parameterless protected procedure, in clock cycles. This is the execution time not directly attributable to the handler procedure or the interrupted execution. It is estimated as C - (A+B), where A is how long it takes to complete a given sequence of instructions without any interrupt, B is how long it takes to complete a normal call to a given protected procedure, and C is how long it takes to complete the same sequence of instructions when it is interrupted by one execution of the same procedure called via an interrupt.

Implementation Permissions

  1. 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.
  2. 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.
  3. 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.

    Implementation Advice

  4. Whenever possible, the implementation should allow interrupt handlers to be called directly by the hardware.
  5. Whenever practical, the implementation should detect violations of any implementation-defined restrictions before run time.

    NOTES

  6. (4) The Attach_Handler pragma can provide static attachment of handlers to interrupts if the implementation supports preelaboration of protected objects. See section C.4 Preelaboration Requirements.
  7. (5) The ceiling priority of a protected object that one of its procedures is attached to an interrupt should be at least as high as the highest processor priority at which that interrupt will ever be delivered.
  8. (6) Protected procedures can also be attached dynamically to interrupts via operations declared in the predefined package Interrupts.
  9. (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.

Go to the first, previous, next, last section, table of contents.