Contents   Index   Search   Previous   Next

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 C.3.2).

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.
7.a
Discussion: In the case of a protected_type_declaration, an object_declaration of an object of that type need not be at library level.
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 C.3.2). [Such procedures are allowed to be attached to multiple interrupts.]
10
    {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.
11
    {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 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.
12/1
      {8652/0068} {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.
12.a/1
Discussion: {8652/0068} 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.
13
    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

14
    {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.
14.1/1
        {8652/0068} {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.
14.a.1/1
Discussion: {8652/0068} 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.

Metrics

15
    The following metric shall be documented by the implementation:
16
    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.
16.a
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.

Implementation Permissions

17
    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.
17.a
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.
18
    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.
18.a
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.
19
    {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.
19.a
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 Advice

20
    Whenever possible, the implementation should allow interrupt handlers to be called directly by the hardware.
21
    Whenever practical, the implementation should detect violations of any implementation-defined restrictions before run time.
NOTES
22
4  The Attach_Handler pragma can provide static attachment of handlers to interrupts if the implementation supports preelaboration of protected objects. (See C.4.)
23
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.
24
6  Protected procedures can also be attached dynamically to interrupts via operations declared in the predefined package Interrupts.
25
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.

Contents   Index   Search   Previous   Next   Legal