- The form of a pragma Interrupt_Handler is as follows:
- 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).
- 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.
- 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.
- 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
- 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.
- 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. If the check fails, Program_Error is raised.
- 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
- 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.
- 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.
- The following metric shall be documented by the implementation:
- 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.
- 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
- 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.
- 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.
- Whenever possible, the implementation should allow interrupt handlers to
be called directly by the hardware.
- Whenever practical, the implementation should detect violations of any
implementation-defined restrictions 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) 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
(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.
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Page last generated: 95-03-12