C.3.1 Protected Procedure Handlers
Syntax
The form of a
pragma
Interrupt_Handler is as follows:
pragma Interrupt_Handler(
handler_name);
The form of a
pragma
Attach_Handler is as follows:
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).
Legality Rules
Dynamic Semantics
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.]
{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.
{
AI95-00434-01}
{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 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 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.
{
8652/0068}
{
AI95-00121-01}
{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, the
previous handler is restored.
Discussion: {
8652/0068}
{
AI95-00121-01}
{
AI95-00303-01}
If all protected objects for interrupt handlers are declared at the library
level, 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. (An object with an Interrupt_Handler 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.
Erroneous Execution
{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.
{
8652/0068}
{
AI95-00121-01}
{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.
Discussion: {
8652/0068}
{
AI95-00121-01}
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
The following metric
shall be documented by the implementation:
{
AI95-00434-01}
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 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.
Documentation Requirement: The metrics
for interrupt handlers.
Implementation Permissions
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.
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.
Implementation defined: Any restrictions
on a protected procedure or its containing type when a
pragma
Attach_handler or Interrupt_Handler 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.
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.
{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.
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 defined: Any other forms
of interrupt handler supported by the Attach_Handler and Interrupt_Handler
pragmas.
Implementation Advice
Whenever possible, the implementation should allow
interrupt handlers to be called directly by the hardware.
Implementation Advice: Interrupt handlers
should be called directly by the hardware.
Whenever practical, the implementation should detect
violations of any implementation-defined restrictions before run time.
Implementation Advice: Violations of
any implementation-defined restrictions on interrupt handlers should
be detected 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 {
AI95-00434-01}
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
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.
Incompatibilities With Ada 95
{
AI95-00253-01}
{
incompatibilities with Ada 95}
Amendment
Correction: 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 illegal.
Wording Changes from Ada 95
{
8652/0068}
{
AI95-00121-01}
Corrigendum: Clarified the meaning of “the previous handler”
when finalizing protected objects containing interrupt handlers.
{
AI95-00303-01}
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 above.
Sponsored by Ada-Europe