C.3.1 Protected Procedure Handlers
The form of
is as follows:
The form of
is as follows:
Name Resolution Rules
For the Interrupt_Handler and Attach_Handler pragmas,
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
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.
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
is made that the corresponding interrupt is not reserved.
is raised if the check fails, and the existing treatment for the interrupt
is not affected.
the Ceiling_Locking policy (see D.3
) is in
effect, then upon the initialization of a protected object for which
either an Attach_Handler or Interrupt_Handler pragma applies to one of
its procedures, a check is made that the ceiling priority defined in
is in the range of System.Interrupt_Priority.
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. 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, the previous handler is restored.
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
) 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.
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.
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
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
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 A protected object that has a (protected)
procedure attached to an interrupt should have a ceiling priority 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
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.