C.3 Interrupt Support
[This clause specifies the language-defined model
for hardware interrupts in addition to mechanisms for handling interrupts.]
{signal: See interrupt} Dynamic Semantics
{interrupt}
[An
interrupt represents a class of events
that are detected by the hardware or the system software.]
{occurrence
(of an interrupt)} Interrupts are said
to occur. An
occurrence of an interrupt is separable into generation
and delivery.
{generation (of an interrupt)}
Generation of an interrupt is the event in
the underlying hardware or system that makes the interrupt available
to the program.
{delivery (of an interrupt)}
Delivery is the action that invokes part of
the program as response to the interrupt occurrence.
{pending
interrupt occurrence} Between generation
and delivery, the interrupt occurrence [(or interrupt)] is
pending.
{blocked interrupt} Some
or all interrupts may be
blocked. When an interrupt is blocked,
all occurrences of that interrupt are prevented from being delivered.
{attaching (to an interrupt)}
{reserved interrupt}
Certain interrupts are
reserved. The set of
reserved interrupts is implementation defined. A reserved interrupt is
either an interrupt for which user-defined handlers are not supported,
or one which already has an attached handler by some other implementation-defined
means.
{interrupt handler}
{handler (interrupt)
[partial]} Program units can be connected
to non-reserved interrupts. While connected, the program unit is said
to be
attached to that interrupt. The execution of that program
unit, the
interrupt handler, is invoked upon delivery of the interrupt
occurrence.
This paragraph
was deleted.
To be honest: As an obsolescent feature,
interrupts may be attached to task entries by an address clause. See
J.7.1.
While a handler is attached to an interrupt, it is
called once for each delivered occurrence of that interrupt. While the
handler executes, the corresponding interrupt is blocked.
While an interrupt is blocked, all occurrences of
that interrupt are prevented from being delivered. Whether such occurrences
remain pending or are lost is implementation defined.
{default treatment}
Each interrupt has a
default treatment which
determines the system's response to an occurrence of that interrupt when
no user-defined handler is attached. The set of possible default treatments
is implementation defined, as is the method (if one exists) for configuring
the default treatments for interrupts.
An interrupt is delivered to the handler (or default
treatment) that is in effect for that interrupt at the time of delivery.
An exception propagated from a handler that is invoked
by an interrupt has no effect.
[If the Ceiling_Locking policy (see
D.3)
is in effect, the interrupt handler executes with the active priority
that is the ceiling priority of the corresponding protected object.]
Implementation Requirements
The implementation shall provide a mechanism to determine
the minimum stack space that is needed for each interrupt handler and
to reserve that space for the execution of the handler. [This space should
accommodate nested invocations of the handler where the system permits
this.]
If the hardware or the underlying system holds pending
interrupt occurrences, the implementation shall provide for later delivery
of these occurrences to the program.
If the Ceiling_Locking policy is not in effect, the
implementation shall provide means for the application to specify whether
interrupts are to be blocked during protected actions.
Documentation Requirements
The implementation
shall document the following items:
Discussion: This information may be different
for different forms of interrupt handlers.
1.
For each interrupt, which interrupts are blocked from delivery when a
handler attached to that interrupt executes (either as a result of an
interrupt delivery or of an ordinary call on a procedure of the corresponding
protected object).
2.
Any interrupts that cannot be blocked, and the effect of attaching handlers
to such interrupts, if this is permitted.
3.
Which run-time stack an interrupt handler uses when it executes as a
result of an interrupt delivery; if this is configurable, what is the
mechanism to do so; how to specify how much space to reserve on that
stack.
4.
Any implementation- or hardware-specific activity that happens before
a user-defined interrupt handler gets control (e.g., reading device registers,
acknowledging devices).
5.
Any timing or other limitations imposed on the execution of interrupt
handlers.
6.
The state (blocked/unblocked) of the non-reserved interrupts when the
program starts; if some interrupts are unblocked, what is the mechanism
a program can use to protect itself before it can attach the corresponding
handlers.
7.
Whether the interrupted task is allowed to resume execution before the
interrupt handler returns.
8.
The treatment of interrupt occurrences that are generated while the interrupt
is blocked; i.e., whether one or more occurrences are held for later
delivery, or all are lost.
9.
Whether predefined or implementation-defined exceptions are raised as
a result of the occurrence of any interrupt, and the mapping between
the machine interrupts (or traps) and the predefined exceptions.
10.
On a multi-processor, the rules governing the delivery of an interrupt
to a particular processor.
Documentation Requirement: The treatment
of interrupts.
Implementation Permissions
{
AI95-00434-01}
If the underlying system or hardware does not allow interrupts to be
blocked, then no blocking is required [as part of the execution of subprograms
of a protected object for which one of its subprograms is an interrupt
handler].
In a multi-processor with more than one interrupt
subsystem, it is implementation defined whether (and how) interrupt sources
from separate subsystems share the same Interrupt_ID type (see
C.3.2).
In particular, the meaning of a blocked or pending interrupt may then
be applicable to one processor only.
Discussion: This issue is tightly related
to the issue of scheduling on a multi-processor. In a sense, if a particular
interrupt source is not available to all processors, the system is not
truly homogeneous.
One way to approach this problem is to assign
sub-ranges within Interrupt_ID to each interrupt subsystem, such that
“similar” interrupt sources (e.g. a timer) in different subsystems
get a distinct id.
Implementations are allowed to impose timing or other
limitations on the execution of interrupt handlers.
Reason: These limitations are often necessary
to ensure proper behavior of the implementation.
{
AI95-00434-01}
Other forms of handlers are allowed to be supported, in which case the
rules of this clause should be adhered to.
The active priority of the execution of an interrupt
handler is allowed to vary from one occurrence of the same interrupt
to another.
Implementation Advice
{
AI95-00434-01}
If the Ceiling_Locking policy is not in effect, the implementation should
provide means for the application to specify which interrupts are to
be blocked during protected actions, if the underlying system allows
for finer-grained control of interrupt blocking.
Implementation Advice: If the Ceiling_Locking
policy is not in effect and the target system allows for finer-grained
control of interrupt blocking, a means for the application to specify
which interrupts are to be blocked during protected actions should be
provided.
1 The default treatment for an interrupt
can be to keep the interrupt pending or to deliver it to an implementation-defined
handler. Examples of actions that an implementation-defined handler is
allowed to perform include aborting the partition, ignoring (i.e., discarding
occurrences of) the interrupt, or queuing one or more occurrences of
the interrupt for possible later delivery when a user-defined handler
is attached to that interrupt.
2 It is a bounded error to call Task_Identification.Current_Task
(see
C.7.1) from an interrupt handler.
3 The rule that an exception propagated
from an interrupt handler has no effect is modeled after the rule about
exceptions propagated out of task bodies.
Sponsored by Ada-Europe