- (1)
- This clause specifies the language-defined model for hardware interrupts
in addition to mechanisms for handling interrupts.
Dynamic Semantics
- (2)
- An interrupt represents 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 occurrence.
Between generation and delivery, the interrupt occurrence (or interrupt) is
pending. Some 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 implementation-defined means. 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.
- (3)
- 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.
- (4)
- 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.
- (5)
- 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.
- (6)
- An interrupt is delivered to the handler (or default treatment) that is
in effect for that interrupt at the time of delivery.
- (7)
- An exception propagated from a handler that is invoked by an interrupt
has no effect.
- (8)
- 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
- (9)
- 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.
- (10)
- If the hardware or the underlying system holds pending interrupt
occurrences, the implementation shall provide for later delivery of these
occurrences to the program.
- (11)
- 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
- (12)
- The implementation shall document the following items:
- (13)
- 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).
- (14)
- Any interrupts that cannot be blocked, and the effect of
attaching handlers to such interrupts, if this is permitted.
- (15)
- 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.
- (16)
- Any implementation- or hardware-specific activity that happens
before a user-defined interrupt handler gets control (e.g.,
reading device registers, acknowledging devices).
- (17)
- Any timing or other limitations imposed on the execution of
interrupt handlers.
- (18)
- 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.
- (19)
- Whether the interrupted task is allowed to resume execution
before the interrupt handler returns.
- (20)
- 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.
- (21)
- 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.
- (22)
- On a multi-processor, the rules governing the delivery of an
interrupt to a particular processor.
Implementation Permissions
- (23)
- 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.
- (24)
- 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.
- (25)
- Implementations are allowed to impose timing or other limitations on the
execution of interrupt handlers.
- (26)
- Other forms of handlers are allowed to be supported, in which case, the
rules of this subclause should be adhered to.
- (27)
- 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
- (28)
- 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.
-
- (29)
(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.
- (30)
(2) It is a bounded error to call Task_Identification.Current_Task (see
C.7.1) from an interrupt handler.
- (31)
(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.
Subclauses
- Protected Procedure Handlers
- The Package Interrupts
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Copyright statement
Page last generated: 95-03-12
| 
| 
| 
| 