C.3.1 Protected Procedure Handlers
Name Resolution Rules
For the Interrupt_Handler and Attach_Handler pragmas,
shall resolve to denote a protected procedure with a parameterless profile.
For a parameterless protected procedure, the following
language-defined representation aspects may be specified:
The type of aspect Interrupt_Handler is Boolean.
If directly specified, the aspect_definition shall be a static expression.
[This aspect is never inherited;] if not directly specified, the aspect
for Interrupt_Handler: Protected
procedure may be attached to interrupts.
The aspect Attach_Handler is an expression,
which shall be of type Interrupts.Interrupt_Id. [This aspect is never
for Attach_Handler: Protected
procedure is attached to an interrupt.
If either the The
Attach_Handler or Interrupt_Handler aspect are
specified for a protected procedure, the pragma
is only allowed immediately within the protected_definition
where the corresponding subprogram is declared. The
shall be a library-
level declaration and shall not be declared within a generic body. In
addition to the places where Legality Rules normally apply (see 12.3),
this rule also applies in the private part of an instance of a generic
We cannot allow these aspects in protected declarations
in a generic body, because legality rules are not checked for instance
bodies, and these should not be allowed if the instance is not at the
library level. The protected types can be declared in the private part
if this is desired. Note that while the 'Access to use the handler would
provide the check in the case of Interrupt_Handler, there is no other
check for Attach_Handler. Since these aspects are so similar, we want
the rules to be the same.
If the pragma
of a protected procedure is True appears
in a protected_definition
then the corresponding
procedure may can
be attached dynamically, as a handler, to interrupts (see C.3.2
[Such procedures are allowed to be attached to multiple interrupts.]
specified for in
the Attach_Handler aspect of a protected procedure
P is evaluated as part of the creation of the protected object
that contains P. The value of the expression
identifies pragma [as evaluated at object
creation time] specifies
an interrupt. As part of the initialization
of that object, P ( if
the Attach_Handler pragma is specified,
is attached to the identified specified
A check 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.
If the Ceiling_Locking
policy (see D.3
) is in effect,
then upon the initialization of a protected object that
contains a protected procedure for which that
either the an
Attach_Handler aspect is specified
Interrupt_Handler aspect is True pragma
applies to one of its procedures
, a check is made that the initial
ceiling priority of the object defined
in the protected_definition
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 the an Attach_Handler aspect pragma was specified 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 specified]
, the previous handler is restored.
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
procedures with an
Attach_Handler aspect specified 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 aspect 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.
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 aspect 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 aspect 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.
This simplifies implementation of the Attach_Handler
aspect 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:
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 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
The metrics for interrupt handlers.
When the aspects pragmas
Attach_Handler or Interrupt_Handler are specified
for apply to
a protected procedure,
the implementation is allowed to impose implementation-defined restrictions
on the corresponding protected_type_declaration
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
Implementation defined: Any
restrictions on a protected procedure or its containing type when an
pragma Attach_handler or Interrupt_Handler is specified 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.
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 what this subclause says elsewhere,
the Attach_Handler and Interrupt_Handler aspects pragmas
are allowed to be used for other, implementation defined, forms of interrupt
For example, if an implementation wishes to allow interrupt handlers
to have parameters, it is allowed to do so via these aspects pragmas
it need not invent implementation-defined aspects pragmas
for the purpose.
Implementation defined: Any
other forms of interrupt handler supported by the Attach_Handler and
Interrupt_Handler aspects pragmas.
Whenever possible, the implementation should allow
interrupt handlers to be called directly by the hardware.
Interrupt handlers should be called
directly by the hardware.
Whenever practical, the implementation should detect
violations of any implementation-defined restrictions before run time.
Violations of any implementation-defined
restrictions on interrupt handlers should be detected before run time.
The Attach_Handler aspect may pragma
provide static attachment of handlers to interrupts if the
implementation supports preelaboration of protected objects. (See C.4
A The ceiling priority
protected object that has a (protected)
procedure one of its procedures is
attached to an interrupt should have a ceiling
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.
Incompatibilities With Ada 95
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
Wording Changes from Ada 95
Corrigendum: Clarified the meaning of “the
previous handler” when finalizing protected objects containing
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
Extensions to Ada 2005
Aspects Interrupt_Handler and
Attach_Handler are new; pragmas
Interrupt_Handler and Attach_Handler are now obsolescent.
Wording Changes from Ada 2005
Correction: Added missing
generic contract wording for the aspects Attach_Handler and Interrupt_Handler.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe