J.7.1 Interrupt Entries
Implementations are permitted to allow the attachment
of task entries to interrupts via the address clause. Such an entry is
referred to as an interrupt entry.
The address of the task entry corresponds to a hardware
interrupt in an implementation-defined manner. (See Ada.Interrupts.Reference
The following attribute
For any task entry
For a task entry whose address is specified (an interrupt entry),
the value refers to the corresponding hardware interrupt. For such an
entry, as for any other task entry, the meaning of this value is implementation
defined. The value of this attribute is of the type of the subtype System.Address.
Address may be specified
for single entries via an attribute_definition_clause
As part of the initialization
of a task object, the address clause for an interrupt entry is elaborated,
which evaluates the expression
of the address clause. A check is made that the address specified is
associated with some interrupt to which a task entry may be attached.
If this check fails, Program_Error is raised. Otherwise,
the interrupt entry is attached to the interrupt associated with the
Upon finalization of the task
object, the interrupt entry, if any, is detached from the corresponding
interrupt and the default treatment is restored.
While an interrupt entry is attached to an interrupt,
the interrupt is reserved (see C.3
An interrupt delivered to a task entry acts as a
call to the entry issued by a hardware task whose priority is in the
System.Interrupt_Priority range. It is implementation defined whether
the call is performed as an ordinary entry call, a timed entry call,
or a conditional entry call; which kind of call is performed can depend
on the specific interrupt.
Bounded (Run-Time) Errors
It is a bounded error to evaluate
E'Caller (see C.7.1
) in an accept_statement
for an interrupt entry. The possible effects are the same as for calling
Current_Task from an entry body.
The implementation shall document to which interrupts
a task entry may be attached.
The implementation shall document whether the invocation
of an interrupt entry has the effect of an ordinary entry call, conditional
call, or a timed call, and whether the effect varies in the presence
of pending interrupts.
The support for this subclause is optional.
Interrupts to which the implementation allows a task
entry to be attached may be designated as reserved for the entire duration
of program execution; that is, not just when they have an interrupt entry
attached to them.
Interrupt entry calls may be implemented by having
the hardware execute directly the appropriate accept_statement
Alternatively, the implementation is allowed to provide an internal interrupt
handler to simulate the effect of a normal task calling the entry.
The implementation is allowed to impose restrictions
on the specifications and bodies of tasks that have interrupt entries.
It is implementation defined whether direct calls
(from the program) to interrupt entries are allowed.
NOTE 1 Queued interrupts correspond
to ordinary entry calls. Interrupts that are lost if not immediately
processed correspond to conditional entry calls. It is a consequence
of the priority rules that an accept_statement
executed in response to an interrupt can be executed with the active
priority at which the hardware generates the interrupt, taking precedence
over lower priority tasks, without a scheduling action.
NOTE 2 Control information that is
supplied upon an interrupt can be passed to an associated interrupt entry
as one or more parameters of mode in.
Example of an interrupt
task Interrupt_Handler is
for Done'Address use Ada.Interrupts.Reference(Ada.Interrupts.Names.Device_Done);
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe