C.3.1 Protected Procedure Handlers
Static Semantics
{
AI05-0229-1}
For a parameterless protected procedure, the following language-defined
representation aspects may be specified:
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.
Aspect Description for Interrupt_Handler:
Protected procedure may be attached to interrupts.
Attach_Handler
The aspect Attach_Handler is an
expression,
which shall be of type Interrupts.Interrupt_Id. [This aspect is never
inherited.]
Aspect Description for Attach_Handler:
Protected procedure is attached to an interrupt.
Legality Rules
{
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.
Dynamic Semantics
{
AI05-0229-1}
If the Interrupt_Handler aspect of a protected procedure is True, then
the procedure may be attached dynamically, as a handler, to interrupts
(see
C.3.2). [Such procedures are allowed
to be attached to multiple interrupts.]
{
AI05-0229-1}
The
expression
specified for 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 an interrupt. As part of the initialization of that object,
P (the
handler procedure) is attached to the identified
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.
{
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 either the Attach_Handler aspect is specified or the Interrupt_Handler
aspect is True, a check is made that the initial ceiling priority of
the object is in the range of System.Interrupt_Priority.
If
the check fails, Program_Error is raised.
{
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 Attach_Handler aspect was specified 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}
{
AI05-0229-1}
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 procedures with an Attach_Handler aspect specified 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 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.
{
AI12-0252-1}
If restriction No_Dynamic_Attachment is in effect, then a check is made
that the interrupt identified by an Attach_Handler aspect does not appear
in any previously elaborated Attach_Handler aspect;
Program_Error
is raised if this check fails.
Reason: When No_Dynamic_Attachment is
in effect, it is not possible to call any previous handler. Therefore,
the only possibility is to replace the original handler, rendering it
ineffective. Having an unused handler in a program is likely a bug, so
we require an exception to be raised.
Erroneous Execution
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}
{
AI05-0229-1}
If the handlers for a given interrupt attached via
aspect 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 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}
{
AI05-0229-1}
This simplifies implementation of the Attach_Handler aspect 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
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 an aspect Attach_handler
or Interrupt_Handler is specified.
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.
{
AI05-0229-1}
Notwithstanding what this subclause says elsewhere,
the Attach_Handler and Interrupt_Handler aspects are allowed to be used
for other, implementation defined, forms of interrupt handlers.
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; it need
not invent implementation-defined aspects for the purpose.
Implementation defined: Any other forms
of interrupt handler supported by the Attach_Handler and Interrupt_Handler
aspects.
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.
NOTE 1 {
AI05-0229-1}
{
AI12-0440-1}
The Attach_Handler aspect can provide static attachment of handlers to
interrupts if the implementation supports preelaboration of protected
objects. (See
C.4.)
NOTE 2 {
AI95-00434-01}
{
AI12-0442-1}
For a protected object that has a (protected) procedure attached to an
interrupt, the correct ceiling priority is at least as high as the highest
processor priority at which that interrupt will ever be delivered.
NOTE 3 Protected procedures can also
be attached dynamically to interrupts via operations declared in the
predefined package Interrupts.
NOTE 4 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}
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.
Extensions to Ada 2005
{
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
{
AI05-0033-1}
Correction: Added missing generic contract
wording for the aspects Attach_Handler and Interrupt_Handler.
Inconsistencies With Ada 2012
{
AI12-0252-1}
Correction: Program_Error might be raised
if two handlers are attached when restriction No_Dynamic_Attachment is
in effect (including as part of the Ravenscar profile). Original Ada
2012 would have just ignored the first handler. This is almost certainly
a bug rather than an intended result.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
