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/2
{
AI95-00434-01}
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/2
{
AI95-00253-01}
{
AI95-00303-01}
The Interrupt_Handler pragma is only allowed immediately within
the a
protected_definition where the corresponding subprogram is declared. The corresponding
protected_type_declaration or
single_protected_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/2
{
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 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}
{
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 Otherwise, [that is, if
an Attach_Handler pragma was used], the previous handler is restored.
12.a/2
Discussion: {
8652/0068}
{
AI95-00121-01}
{
AI95-00303-01}
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. (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.)
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}
{
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. 14.a.1/1
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
15
The following metric
shall be documented by the implementation:
16/2
- {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.
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.
16.b/2
Documentation Requirement:
The metrics for interrupt handlers.
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.
17.b/2
Implementation defined:
Any restrictions on a protected procedure
or its containing type when a pragma Attach_handler
or Interrupt_Handler applies.
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.
19.b/2
Implementation defined:
Any other forms of interrupt handler
supported by the Attach_Handler and Interrupt_Handler pragmas.
Implementation Advice
20
Whenever possible, the implementation should allow
interrupt handlers to be called directly by the hardware.
20.a/2
Implementation Advice:
Interrupt handlers should be called
directly by the hardware.
21
Whenever practical, the implementation should detect
violations of any implementation-defined restrictions before run time.
21.a/2
Implementation Advice:
Violations of any implementation-defined
restrictions on interrupt handlers should be detected before run time.
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/2
5 {
AI95-00434-01}
A The ceiling priority
of a protected object that
has a (protected)
procedure one of its procedures is
attached to an interrupt should
have a ceiling
priority 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.
Incompatibilities With Ada 95
25.a/2
{
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
25.b/2
{
8652/0068}
{
AI95-00121-01}
Corrigendum: Clarified the meaning of “the
previous handler” when finalizing protected objects containing
interrupt handlers.25.c/2
{
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