C.3.1 Protected Procedure Handlers
Syntax
1/3
2/3
3/3
4/3
Name Resolution Rules
5/3
{
AI05-0229-1}
For the Interrupt_Handler and Attach_Handler pragmas,
the handler_name
shall resolve to denote a protected procedure with a parameterless profile.6/3
Static Semantics
6.1/3
{
AI05-0229-1}
For a parameterless protected procedure, the following
language-defined representation aspects may be specified: 6.2/3
Interrupt_Handler
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
is False.
6.a/3
Aspect Description
for Interrupt_Handler: Protected
procedure may be attached to interrupts.
6.3/3
Attach_Handler
The aspect Attach_Handler is an expression,
which shall be of type Interrupts.Interrupt_Id. [This aspect is never
inherited.]
6.b/3
Aspect Description
for Attach_Handler: Protected
procedure is attached to an interrupt.
Legality Rules
7/3
{
AI95-00434-01}
{
AI05-0033-1}
{
AI05-0229-1}
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 corresponding
protected_type_declaration
or
single_protected_declaration
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
unit.
7.a
7.b/3
{
AI05-0033-1}
{
AI05-0229-1}
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. 8/3
Dynamic Semantics
9/3
{
AI05-0229-1}
If the
pragma Interrupt_Handler
aspect
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.]
10/3
{
AI05-0229-1}
The
expression
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, the
handler procedure
)
is attached to the
identified 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/3
{
AI95-00434-01}
{
AI05-0229-1}
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 or
the
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.
If
the check fails, Program_Error is raised.
12/3
{
8652/0068}
{
AI95-00121-01}
{
AI05-0229-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 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.
12.a/3
Discussion: {
8652/0068}
{
AI95-00121-01}
{
AI95-00303-01}
{
AI05-0229-1}
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.)
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/3
{
8652/0068}
{
AI95-00121-01}
{
AI05-0229-1}
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. 14.a/3
Discussion: {
8652/0068}
{
AI95-00121-01}
{
AI05-0229-1}
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.
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/3
{
AI05-0229-1}
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
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/3
Implementation defined: Any
restrictions on a protected procedure or its containing type when an
aspect a
pragma Attach_handler or Interrupt_Handler is specified 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/3
{
AI05-0229-1}
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
handlers.
19.a/3
Ramification: {
AI05-0229-1}
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.
19.b/3
Implementation defined: Any
other forms of interrupt handler supported by the Attach_Handler and
Interrupt_Handler aspects 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/3
4 {
AI05-0229-1}
The Attach_Handler
aspect may 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}
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. Extensions to Ada 2005
25.d/3
{
AI05-0229-1}
Aspects Interrupt_Handler and
Attach_Handler are new; pragmas
Interrupt_Handler and Attach_Handler are now obsolescent. Wording Changes from Ada 2005
25.e/3
{
AI05-0033-1}
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
