Contents Index Search Previous Next
C.3 Interrupt Support
This clause specifies the language-defined model
for hardware interrupts in addition to mechanisms for handling interrupts.
a class of events that are detected by the hardware or the system software.
Interrupts are said to occur. An occurrence
of an interrupt is separable into generation and delivery. Generation
of an interrupt is the event in the underlying hardware or system that
makes the interrupt available to the program. Delivery
is the action that invokes part of the program as response to the interrupt
Between generation and delivery, the
interrupt occurrence (or interrupt) is pending
or all interrupts may be blocked
. When an interrupt is blocked,
all occurrences of that interrupt are prevented from being delivered.
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
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.
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.
Each interrupt has a default
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.
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
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.
shall document the following items:
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
Any interrupts that cannot be blocked, and the effect of attaching handlers
to such interrupts, if this is permitted.
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
Any implementation- or hardware-specific activity that happens before
a user-defined interrupt handler gets control (e.g., reading device registers,
Any timing or other limitations imposed on the execution of interrupt
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
Whether the interrupted task is allowed to resume execution before the
interrupt handler returns.
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.
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.
On a multi-processor, the rules governing the delivery of an interrupt
to a particular processor.
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 whose 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.
Implementations are allowed to impose timing
or other limitations on the execution of interrupt handlers.
Other forms of handlers are allowed to be supported,
in which case, the rules of this subclause 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
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 a finer-grain control of interrupt blocking.
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.
Contents Index Search Previous Next Legal