1
[This clause specifies the language−defined model for hardware interrupts in addition to mechanisms for handling interrupts.] {signal: See interrupt}
2
{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.
2.a/2
This paragraph was deleted.
2.b
To be honest: As an obsolescent feature, interrupts may be attached to task entries by an address clause. See J.7.1.
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
{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.
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.]
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.
12
The implementation shall document the following items:
12.a
Discussion: This information may be different for different forms of interrupt handlers.
13
14
15
16
17
18
19
20
21
22
22.a/2
Documentation Requirement: The treatment of interrupts.
23/2
{00434AI95−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].
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.
24.a
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.
24.b
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.
25
Implementations are allowed to impose timing or other limitations on the execution of interrupt handlers.
25.a
Reason: These limitations are often necessary to ensure proper behavior of the implementation.
26/2
{00434AI95−00434−01} Other forms of handlers are allowed to be supported, in which case the rules of this clause 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.
28/2
{00434AI95−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.
28.a/2
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.
NOTES
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.