Contents Index Search Related Documents Previous Next
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
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.
8/2
The Interrupt_Handler pragma is only allowed
immediately within a protected_definition
where the corresponding subprogram is declared. The corresponding protected_type_declaration
or single_protected_declaration
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
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.
11/2
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.
If the check
fails, Program_Error is raised.
12/1
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.
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
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
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.
Metrics
15
The following metric
shall be documented by the implementation:
16/2
- 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 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.
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.
19
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.
Implementation Advice
20
Whenever possible, the implementation should
allow interrupt handlers to be called directly by the hardware.
21
Whenever practical, the implementation should
detect violations of any implementation-defined restrictions 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 The ceiling priority
of a protected object for which 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 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.
Contents Index Search Related Documents Previous Next Legal