Annex C
(normative)
Systems Programming
1 [{systems programming} {low-level programming} {real-time systems}
{embedded systems} {distributed systems} {information systems} The Systems
Programming Annex specifies additional capabilities provided for low-level
programming. These capabilities are also required in many real-time, embedded,
distributed, and information systems.]
Extensions to Ada 83
1.a {extensions to Ada 83} This Annex is new to Ada 95.
C.1 Access to Machine Operations
1 [This clause specifies rules regarding access to machine instructions from
within an Ada program.]
1.a/2 Implementation defined: Implementation-defined intrinsic
subprograms.
Implementation Requirements
2 {machine code insertion} The implementation shall support machine code
insertions (see 13.8) or intrinsic subprograms (see 6.3.1) (or both).
Implementation-defined attributes shall be provided to allow the use of Ada
entities as operands.
Implementation Advice
3 The machine code or intrinsics support should allow access to all
operations normally available to assembly language programmers for the target
environment, including privileged instructions, if any.
3.a.1/2 Implementation Advice: The machine code or intrinsics support
should allow access to all operations normally available to
assembly language programmers for the target environment.
3.a Ramification: Of course, on a machine with protection, an attempt
to execute a privileged instruction in user mode will probably
trap. Nonetheless, we want implementations to provide access to
them so that Ada can be used to write systems programs that run in
privileged mode.
4 {interface to assembly language} {language (interface to assembly)}
{mixed-language programs} {assembly language} The interfacing pragmas (see
Annex B) should support interface to assembler; the default assembler should
be associated with the convention identifier Assembler.
4.a/2 Implementation Advice: Interface to assembler should be supported;
the default assembler should be associated with the convention
identifier Assembler.
5 If an entity is exported to assembly language, then the implementation
should allocate it at an addressable location, and should ensure that it is
retained by the linking process, even if not otherwise referenced from the Ada
code. The implementation should assume that any call to a machine code or
assembler subprogram is allowed to read or update every object that is
specified as exported.
5.a/2 Implementation Advice: If an entity is exported to assembly
language, then the implementation should allocate it at an
addressable location even if not otherwise referenced from the Ada
code. A call to a machine code or assembler subprogram should be
treated as if it could read or update every object that is
specified as exported.
Documentation Requirements
6 The implementation shall document the overhead associated with calling
machine-code or intrinsic subprograms, as compared to a fully-inlined call,
and to a regular out-of-line call.
6.a/2 Documentation Requirement: The overhead of calling machine-code or
intrinsic subprograms.
7 The implementation shall document the types of the package
System.Machine_Code usable for machine code insertions, and the attributes to
be used in machine code insertions for references to Ada entities.
7.a/2 Documentation Requirement: The types and attributes used in
machine code insertions.
8 The implementation shall document the subprogram calling conventions
associated with the convention identifiers available for use with the
interfacing pragmas (Ada and Assembler, at a minimum), including register
saving, exception propagation, parameter passing, and function value
returning.
8.a/2 Documentation Requirement: The subprogram calling conventions for
all supported convention identifiers.
9 For exported and imported subprograms, the implementation shall document
the mapping between the Link_Name string, if specified, or the Ada designator,
if not, and the external link name used for such a subprogram.
9.a/2 This paragraph was deleted.
9.b/2 Documentation Requirement: The mapping between the Link_Name or
Ada designator and the external link name.
Implementation Advice
10 The implementation should ensure that little or no overhead is associated
with calling intrinsic and machine-code subprograms.
10.a/2 Implementation Advice: Little or no overhead should be associated
with calling intrinsic and machine-code subprograms.
11 It is recommended that intrinsic subprograms be provided for convenient
access to any machine operations that provide special capabilities or
efficiency and that are not otherwise available through the language
constructs. Examples of such instructions include:
12 * Atomic read-modify-write operations - e.g., test and set, compare and
swap, decrement and test, enqueue/dequeue.
13 * Standard numeric functions - e.g., sin, log.
14 * String manipulation operations - e.g., translate and test.
15 * Vector operations - e.g., compare vector against thresholds.
16 * Direct operations on I/O ports.
16.a/2 Implementation Advice: Intrinsic subprograms should be provided to
access any machine operations that provide special capabilities or
efficiency not normally available.
C.2 Required Representation Support
1/2 {AI95-00434-01} This clause specifies minimal requirements on the support
for representation items and related features.
Implementation Requirements
2 {recommended level of support (required in Systems Programming Annex)
[partial]} The implementation shall support at least the functionality
defined by the recommended levels of support in Section 13.
C.3 Interrupt Support
1 [This clause specifies the language-defined model for hardware interrupts
in addition to mechanisms for handling interrupts.] {signal: See interrupt}
Dynamic Semantics
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.]
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:
12.a Discussion: This information may be different for different forms
of interrupt handlers.
13 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).
14 2. Any interrupts that cannot be blocked, and the effect of attaching
handlers to such interrupts, if this is permitted.
15 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.
16 4. Any implementation- or hardware-specific activity that happens before
a user-defined interrupt handler gets control (e.g., reading device
registers, acknowledging devices).
17 5. Any timing or other limitations imposed on the execution of interrupt
handlers.
18 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.
19 7. Whether the interrupted task is allowed to resume execution before the
interrupt handler returns.
20 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.
21 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.
22 10. On a multi-processor, the rules governing the delivery of an interrupt
to a particular processor.
22.a/2 Documentation Requirement: The treatment of interrupts.
Implementation Permissions
23/2 {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].
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 {AI95-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.
Implementation Advice
28/2 {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.
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.
C.3.1 Protected Procedure Handlers
Syntax
1 The form of a pragma Interrupt_Handler is as follows:
2 pragma Interrupt_Handler(handler_name);
3 The form of a pragma Attach_Handler is as follows:
4 pragma Attach_Handler(handler_name, expression);
Name Resolution Rules
5 For the Interrupt_Handler and Attach_Handler pragmas, the handler_name
shall resolve to denote a protected procedure with a parameterless profile.
6 For the Attach_Handler pragma, the expected type for the expression is
Interrupts.Interrupt_ID (see C.3.2).
Legality Rules
7/2 {AI95-00434-01} The Attach_Handler pragma is only allowed immediately
within the protected_definition where the corresponding subprogram is
declared. The corresponding protected_type_declaration or single_protected_-
declaration shall be a library-level declaration.
7.a Discussion: In the case of a protected_type_declaration, an
object_declaration of an object of that type need not be at
library level.
8/2 {AI95-00253-01} {AI95-00303-01} The Interrupt_Handler pragma is only
allowed immediately within the protected_definition where the corresponding
subprogram is declared. The corresponding protected_type_declaration or single_-
protected_declaration shall be a library-level declaration.
Dynamic Semantics
9 If the pragma Interrupt_Handler appears in a protected_definition, then
the corresponding procedure can be attached dynamically, as a handler, to
interrupts (see C.3.2). [Such procedures are allowed to be attached to
multiple interrupts.]
10 {creation (of a protected object)}
{initialization (of a protected object)} The expression in the Attach_Handler
pragma [as evaluated at object creation time] specifies an interrupt. As part
of the initialization of that object, if the Attach_Handler pragma is
specified, the handler procedure is attached to the specified interrupt.
{Reserved_Check [partial]} {check, language-defined (Reserved_Check)} A check
is made that the corresponding interrupt is not reserved.
{Program_Error (raised by failure of run-time check)} Program_Error is raised
if the check fails, and the existing treatment for the interrupt is not
affected.
11/2 {AI95-00434-01} {initialization (of a protected object)} {Ceiling_Check
[partial]} {check, language-defined (Ceiling_Check)} If the Ceiling_Locking
policy (see D.3) is in effect, then upon the initialization of a protected
object for which either an Attach_Handler or Interrupt_Handler pragma applies
to one of its procedures, a check is made that the ceiling priority defined in
the protected_definition is in the range of System.Interrupt_Priority.
{Program_Error (raised by failure of run-time check)} If the check fails,
Program_Error is raised.
12/1 {8652/0068} {AI95-00121-01} {finalization (of a protected object)} When a
protected object is finalized, for any of its procedures that are attached to
interrupts, the handler is detached. If the handler was attached by a
procedure in the Interrupts package or if no user handler was previously
attached to the interrupt, the default treatment is restored. If an Attach_-
Handler pragma was used and the most recently attached handler for the same
interrupt is the same as the one that was attached at the time the protected
object was initialized, the previous handler is restored.
12.a/2 Discussion: {8652/0068} {AI95-00121-01} {AI95-00303-01} If all
protected objects for interrupt handlers are declared at the
library level, the finalization discussed above occurs only as
part of the finalization of all library-level packages in a
partition. However, objects of a protected type containing an
Attach_Handler pragma need not be at the library level. Thus, an
implementation needs to be able to restore handlers during the
execution of the program. (An object with an Interrupt_Handler
pragma also need not be at the library level, but such a handler
cannot be attached to an interrupt using the Interrupts package.)
13 When a handler is attached to an interrupt, the interrupt is blocked
[(subject to the Implementation Permission in C.3)] during the execution of
every protected action on the protected object containing the handler.
Erroneous Execution
14 {erroneous execution (cause) [partial]} If the Ceiling_Locking policy (see
D.3) is in effect and an interrupt is delivered to a handler, and the
interrupt hardware priority is higher than the ceiling priority of the
corresponding protected object, the execution of the program is erroneous.
14.1/1 {8652/0068} {AI95-00121-01} {erroneous execution (cause) [partial]} If
the handlers for a given interrupt attached via pragma Attach_Handler are not
attached and detached in a stack-like (LIFO) order, program execution is
erroneous. In particular, when a protected object is finalized, the execution
is erroneous if any of the procedures of the protected object are attached to
interrupts via pragma Attach_Handler and the most recently attached handler
for the same interrupt is not the same as the one that was attached at the
time the protected object was initialized.
14.a.1/1 Discussion: {8652/0068} {AI95-00121-01} This simplifies
implementation of the Attach_Handler pragma by not requiring a
check that the current handler is the same as the one attached by
the initialization of a protected object.
Metrics
15 The following metric shall be documented by the implementation:
16/2 * {AI95-00434-01} The worst-case overhead for an interrupt handler that
is a parameterless protected procedure, in clock cycles. This is the
execution time not directly attributable to the handler procedure or
the interrupted execution. It is estimated as C - (A+B), where A is
how long it takes to complete a given sequence of instructions without
any interrupt, B is how long it takes to complete a normal call to a
given protected procedure, and C is how long it takes to complete the
same sequence of instructions when it is interrupted by one execution
of the same procedure called via an interrupt.
16.a Implementation Note: The instruction sequence and interrupt
handler used to measure interrupt handling overhead should be
chosen so as to maximize the execution time cost due to cache
misses. For example, if the processor has cache memory and the
activity of an interrupt handler could invalidate the contents of
cache memory, the handler should be written such that it
invalidates all of the cache memory.
16.b/2 Documentation Requirement: The metrics for interrupt handlers.
Implementation Permissions
17 When the pragmas Attach_Handler or Interrupt_Handler apply to a protected
procedure, the implementation is allowed to impose implementation-defined
restrictions on the corresponding protected_type_declaration and protected_-
body.
17.a Ramification: The restrictions may be on the constructs that are
allowed within them, and on ordinary calls (i.e. not via
interrupts) on protected operations in these protected objects.
17.b/2 Implementation defined: Any restrictions on a protected procedure
or its containing type when a pragma Attach_handler or
Interrupt_Handler applies.
18 An implementation may use a different mechanism for invoking a protected
procedure in response to a hardware interrupt than is used for a call to that
protected procedure from a task.
18.a Discussion: This is despite the fact that the priority of an
interrupt handler (see D.1) is modeled after a hardware task
calling the handler.
19 {notwithstanding} Notwithstanding what this subclause says elsewhere, the
Attach_Handler and Interrupt_Handler pragmas are allowed to be used for other,
implementation defined, forms of interrupt handlers.
19.a Ramification: For example, if an implementation wishes to allow
interrupt handlers to have parameters, it is allowed to do so via
these pragmas; it need not invent implementation-defined pragmas
for the purpose.
19.b/2 Implementation defined: Any other forms of interrupt handler
supported by the Attach_Handler and Interrupt_Handler pragmas.
Implementation Advice
20 Whenever possible, the implementation should allow interrupt handlers to
be called directly by the hardware.
20.a/2 Implementation Advice: Interrupt handlers should be called
directly by the hardware.
21 Whenever practical, the implementation should detect violations of any
implementation-defined restrictions before run time.
21.a/2 Implementation Advice: Violations of any implementation-defined
restrictions on interrupt handlers should be detected before run
time.
NOTES
22 4 The Attach_Handler pragma can provide static attachment of handlers
to interrupts if the implementation supports preelaboration of
protected objects. (See C.4.)
23/2 5 {AI95-00434-01} A protected object that has a (protected) procedure
attached to an interrupt should have a ceiling priority at least as
high as the highest processor priority at which that interrupt will
ever be delivered.
24 6 Protected procedures can also be attached dynamically to interrupts
via operations declared in the predefined package Interrupts.
25 7 An example of a possible implementation-defined restriction is
disallowing the use of the standard storage pools within the body of a
protected procedure that is an interrupt handler.
Incompatibilities With Ada 95
25.a/2 {AI95-00253-01} {incompatibilities with Ada 95} Amendment
Correction: Corrected the wording so that the rules for the use of
Attach_Handler and Interrupt_Handler are identical. This means
that uses of pragma Interrupt_Handler outside of the target
protected type or single protected object are now illegal.
Wording Changes from Ada 95
25.b/2 {8652/0068} {AI95-00121-01} Corrigendum: Clarified the meaning of
"the previous handler" when finalizing protected objects
containing interrupt handlers.
25.c/2 {AI95-00303-01} Dropped the requirement that an object of a type
containing an Interrupt_Handler pragma must be declared at the
library level. This was a generic contract model violation. This
change is not an extension, as an attempt to attach such a handler
with a routine in package Interrupts will fail an accessibility
check anyway. Moreover, implementations can retain the rule as an
implementation-defined restriction on the use of the type, as
permitted by the Implementation Permissions above.
C.3.2 The Package Interrupts
Static Semantics
1 The following language-defined packages exist:
2 with System;
package Ada.Interrupts is
type Interrupt_ID is implementation-defined;
type Parameterless_Handler is
access protected procedure;
3/1 This paragraph was deleted.
4 function Is_Reserved (Interrupt : Interrupt_ID)
return Boolean;
5 function Is_Attached (Interrupt : Interrupt_ID)
return Boolean;
6 function Current_Handler (Interrupt : Interrupt_ID)
return Parameterless_Handler;
7 procedure Attach_Handler
(New_Handler : in Parameterless_Handler;
Interrupt : in Interrupt_ID);
8 procedure Exchange_Handler
(Old_Handler : out Parameterless_Handler;
New_Handler : in Parameterless_Handler;
Interrupt : in Interrupt_ID);
9 procedure Detach_Handler
(Interrupt : in Interrupt_ID);
10 function Reference(Interrupt : Interrupt_ID)
return System.Address;
11 private
... -- not specified by the language
end Ada.Interrupts;
12 package Ada.Interrupts.Names is
implementation-defined : constant Interrupt_ID :=
implementation-defined;
. . .
implementation-defined : constant Interrupt_ID :=
implementation-defined;
end Ada.Interrupts.Names;
Dynamic Semantics
13 The Interrupt_ID type is an implementation-defined discrete type used to
identify interrupts.
14 The Is_Reserved function returns True if and only if the specified
interrupt is reserved.
15 The Is_Attached function returns True if and only if a user-specified
interrupt handler is attached to the interrupt.
16/1 {8652/0069} {AI95-00166-01} The Current_Handler function returns a value
that represents the attached handler of the interrupt. If no user-defined
handler is attached to the interrupt, Current_Handler returns null.
17 The Attach_Handler procedure attaches the specified handler to the
interrupt, overriding any existing treatment (including a user handler) in
effect for that interrupt. If New_Handler is null, the default treatment is
restored. {Program_Error (raised by failure of run-time check)} If New_Handler
designates a protected procedure to which the pragma Interrupt_Handler does
not apply, Program_Error is raised. In this case, the operation does not
modify the existing interrupt treatment.
18/1 {8652/0069} {AI95-00166-01} The Exchange_Handler procedure operates in
the same manner as Attach_Handler with the addition that the value returned in
Old_Handler designates the previous treatment for the specified interrupt. If
the previous treatment is not a user-defined handler, null is returned.
18.a Ramification: Calling Attach_Handler or Exchange_Handler with this
value for New_Handler restores the previous handler.
18.a.1/1 {8652/0069} {AI95-00166-01} If the application uses only
parameterless procedures as handlers (other types of handlers may
be provided by the implementation, but are not required by the
standard), then if Old_Handler is not null, it may be called to
execute the previous handler. This provides a way to cascade
application interrupt handlers. However, the default handler
cannot be cascaded this way (Old_Handler must be null for the
default handler).
19 The Detach_Handler procedure restores the default treatment for the
specified interrupt.
20 For all operations defined in this package that take a parameter of type
Interrupt_ID, with the exception of Is_Reserved and Reference, a check is made
that the specified interrupt is not reserved.
{Program_Error (raised by failure of run-time check)} Program_Error is raised
if this check fails.
21 If, by using the Attach_Handler, Detach_Handler, or Exchange_Handler
procedures, an attempt is made to detach a handler that was attached
statically (using the pragma Attach_Handler), the handler is not detached and
Program_Error is raised.
{Program_Error (raised by failure of run-time check)}
22/2 {AI95-00434-01} The Reference function returns a value of type
System.Address that can be used to attach a task entry via an address clause
(see J.7.1) to the interrupt specified by Interrupt. This function raises
Program_Error if attaching task entries to interrupts (or to this particular
interrupt) is not supported.
{Program_Error (raised by failure of run-time check)}
Implementation Requirements
23 At no time during attachment or exchange of handlers shall the current
handler of the corresponding interrupt be undefined.
Documentation Requirements
24/2 {AI95-00434-01} If the Ceiling_Locking policy (see D.3) is in effect, the
implementation shall document the default ceiling priority assigned to a
protected object that contains either the Attach_Handler or Interrupt_Handler
pragmas, but not the Interrupt_Priority pragma. [This default need not be the
same for all interrupts.]
24.a/2 Documentation Requirement: If the Ceiling_Locking policy is in
effect, the default ceiling priority for a protected object that
contains an interrupt handler pragma.
Implementation Advice
25 If implementation-defined forms of interrupt handler procedures are
supported, such as protected procedures with parameters, then for each such
form of a handler, a type analogous to Parameterless_Handler should be
specified in a child package of Interrupts, with the same operations as in the
predefined package Interrupts.
25.a/2 Implementation Advice: If implementation-defined forms of
interrupt handler procedures are supported, then for each such
form of a handler, a type analogous to Parameterless_Handler
should be specified in a child package of Interrupts, with the
same operations as in the predefined package Interrupts.
NOTES
26 8 The package Interrupts.Names contains implementation-defined names
(and constant values) for the interrupts that are supported by the
implementation.
Examples
27 Example of interrupt handlers:
28 Device_Priority : constant
array (1..5) of System.Interrupt_Priority := ( ... );
protected type Device_Interface
(Int_ID : Ada.Interrupts.Interrupt_ID) is
procedure Handler;
pragma Attach_Handler(Handler, Int_ID);
...
pragma Interrupt_Priority(Device_Priority(Int_ID));
end Device_Interface;
...
Device_1_Driver : Device_Interface(1);
...
Device_5_Driver : Device_Interface(5);
...
Wording Changes from Ada 95
28.a/2 {8652/0069} {AI95-00166-01} Corrigendum: Clarified that the value
returned by Current_Handler and Exchange_Handler for the default
treatment is null.
C.4 Preelaboration Requirements
1 [This clause specifies additional implementation and documentation
requirements for the Preelaborate pragma (see 10.2.1).]
Implementation Requirements
2 The implementation shall not incur any run-time overhead for the
elaboration checks of subprograms and protected_bodies declared in
preelaborated library units.
3 The implementation shall not execute any memory write operations after
load time for the elaboration of constant objects declared immediately within
the declarative region of a preelaborated library package, so long as the
subtype and initial expression (or default initial expressions if initialized
by default) of the object_declaration satisfy the following restrictions.
{load time} The meaning of load time is implementation defined.
3.a Discussion: On systems where the image of the partition is
initially copied from disk to RAM, or from ROM to RAM, prior to
starting execution of the partition, the intention is that "load
time" consist of this initial copying step. On other systems, load
time and run time might actually be interspersed.
4 * Any subtype_mark denotes a statically constrained subtype, with
statically constrained subcomponents, if any;
4.1/2 * {AI95-00161-01} no subtype_mark denotes a controlled type, a private
type, a private extension, a generic formal private type, a generic
formal derived type, or a descendant of such a type;
4.a.1/2 Reason: For an implementation that uses the registration method of
finalization, a controlled object will require some code executed
to register the object at the appropriate point. The other types
are those that might have a controlled component. None of these
types were allowed in preelaborated units in Ada 95. These types
are covered by the Implementation Advice, of course, so they
should still execute as little code as possible.
5 * any constraint is a static constraint;
6 * any allocator is for an access-to-constant type;
7 * any uses of predefined operators appear only within static expressions;
8 * any primaries that are names, other than attribute_references for the
Access or Address attributes, appear only within static expressions;
8.a Ramification: This cuts out attribute_references that are not
static, except for Access and Address.
9 * any name that is not part of a static expression is an expanded name
or direct_name that statically denotes some entity;
9.a Ramification: This cuts out function_calls and type_conversions
that are not static, including calls on attribute functions like
'Image and 'Value.
10 * any discrete_choice of an array_aggregate is static;
11 * no language-defined check associated with the elaboration of the
object_declaration can fail.
11.a/2 Reason: {AI95-00114-01} The intent is that aggregates all of whose
scalar subcomponents are static and all of whose access
subcomponents are null, allocators for access-to-constant types,
or X'Access, will be supported with no run-time code generated.
Documentation Requirements
12 The implementation shall document any circumstances under which the
elaboration of a preelaborated package causes code to be executed at run time.
12.a/2 Documentation Requirement: Any circumstances when the elaboration
of a preelaborated package causes code to be executed.
13 The implementation shall document whether the method used for
initialization of preelaborated variables allows a partition to be restarted
without reloading.
13.a.1/2 Documentation Requirement: Whether a partition can be restarted
without reloading.
13.a/2 This paragraph was deleted.
13.b/2 Discussion: {AI95-00114-01} This covers the issue of the run-time
system itself being restartable, so that need not be a separate
Documentation Requirement.
Implementation Advice
14 It is recommended that preelaborated packages be implemented in such a way
that there should be little or no code executed at run time for the
elaboration of entities not already covered by the
Implementation Requirements.
14.a/2 Implementation Advice: Preelaborated packages should be
implemented such that little or no code is executed at run time
for the elaboration of entities.
Wording Changes from Ada 95
14.b/2 {AI95-00161-01} Added wording to exclude the additional kinds of
types allowed in preelaborated units from the
Implementation Requirements.
C.5 Pragma Discard_Names
1 [A pragma Discard_Names may be used to request a reduction in storage used
for the names of certain entities.]
Syntax
2 The form of a pragma Discard_Names is as follows:
3 pragma Discard_Names[([On => ] local_name)];
4 A pragma Discard_Names is allowed only immediately within a
declarative_part, immediately within a package_specification, or as a
configuration pragma. {configuration pragma (Discard_Names)
[partial]} {pragma, configuration (Discard_Names) [partial]}
Legality Rules
5 The local_name (if present) shall denote a non-derived enumeration [first]
subtype, a tagged [first] subtype, or an exception. The pragma applies to the
type or exception. Without a local_name, the pragma applies to all such
entities declared after the pragma, within the same declarative region.
Alternatively, the pragma can be used as a configuration pragma. If the pragma
applies to a type, then it applies also to all descendants of the type.
Static Semantics
6 {representation pragma (Discard_Names) [partial]}
{pragma, representation (Discard_Names) [partial]} If a local_name is given,
then a pragma Discard_Names is a representation pragma.
7/2 {AI95-00285-01} {AI95-00400-01} If the pragma applies to an enumeration
type, then the semantics of the Wide_Wide_Image and Wide_Wide_Value attributes
are implementation defined for that type[; the semantics of Image, Wide_Image,
Value, and Wide_Value are still defined in terms of Wide_Wide_Image and
Wide_Wide_Value]. In addition, the semantics of Text_IO.Enumeration_IO are
implementation defined. If the pragma applies to a tagged type, then the
semantics of the Tags.Wide_Wide_Expanded_Name function are implementation
defined for that type[; the semantics of Tags.Expanded_Name and Tags.Wide_-
Expanded_Name are still defined in terms of Tags.Wide_Wide_Expanded_Name]. If
the pragma applies to an exception, then the semantics of the Exceptions.-
Wide_Wide_Exception_Name function are implementation defined for that
exception[; the semantics of Exceptions.Exception_Name and Exceptions.Wide_-
Exception_Name are still defined in terms of Exceptions.Wide_Wide_Exception_-
Name].
7.a Implementation defined: The semantics of pragma Discard_Names.
7.b Ramification: The Width attribute is still defined in terms of
Image.
7.c/2 {AI95-00285-01} The semantics of S'Wide_Wide_Image and
S'Wide_Wide_Value are implementation defined for any subtype of an
enumeration type to which the pragma applies. (The pragma actually
names the first subtype, of course.)
Implementation Advice
8 If the pragma applies to an entity, then the implementation should reduce
the amount of storage used for storing names associated with that entity.
8.a/2 Implementation Advice: If pragma Discard_Names applies to an
entity, then the amount of storage used for storing names
associated with that entity should be reduced.
8.b Reason: A typical implementation of the Image attribute for
enumeration types is to store a table containing the names of all
the enumeration literals. Pragma Discard_Names allows the
implementation to avoid storing such a table without having to
prove that the Image attribute is never used (which can be
difficult in the presence of separate compilation).
8.c We did not specify the semantics of the Image attribute in the
presence of this pragma because different semantics might be
desirable in different situations. In some cases, it might make
sense to use the Image attribute to print out a useful value that
can be used to identify the entity given information in
compiler-generated listings. In other cases, it might make sense
to get an error at compile time or at run time. In cases where
memory is plentiful, the simplest implementation makes sense:
ignore the pragma. Implementations that are capable of avoiding
the extra storage in cases where the Image attribute is never used
might also wish to ignore the pragma.
8.d The same applies to the Tags.Expanded_Name and
Exceptions.Exception_Name functions.
Wording Changes from Ada 95
8.e/2 {AI95-00285-01} {AI95-00400-01} Updated the wording to reflect
that the double wide image and value functions are now the master
versions that the others are defined from.
C.6 Shared Variable Control
1 [This clause specifies representation pragmas that control the use of
shared variables.]
Syntax
2 The form for pragmas Atomic, Volatile, Atomic_Components, and
Volatile_Components is as follows:
3 pragma Atomic(local_name);
4 pragma Volatile(local_name);
5 pragma Atomic_Components(array_local_name);
6 pragma Volatile_Components(array_local_name);
7/2 {AI95-00272-01} {atomic} An atomic type is one to which a pragma Atomic
applies. An atomic object (including a component) is one to which a pragma
Atomic applies, or a component of an array to which a pragma Atomic_Components
applies, or any object of an atomic type, other than objects obtained by
evaluating a slice.
7.a/2 Ramification: {AI95-00272-01} A slice of an atomic array object is
not itself atomic. That's necessary as executing a read or write
of a dynamic number of components in a single instruction is not
possible on many targets.
8 {volatile} A volatile type is one to which a pragma Volatile applies. A
volatile object (including a component) is one to which a pragma Volatile
applies, or a component of an array to which a pragma Volatile_Components
applies, or any object of a volatile type. In addition, every atomic type or
object is also defined to be volatile. Finally, if an object is volatile, then
so are all of its subcomponents [(the same does not apply to atomic)].
Name Resolution Rules
9 The local_name in an Atomic or Volatile pragma shall resolve to denote
either an object_declaration, a non-inherited component_declaration, or a
full_type_declaration. The array_local_name in an Atomic_Components or
Volatile_Components pragma shall resolve to denote the declaration of an array
type or an array object of an anonymous type.
Legality Rules
10 {indivisible} It is illegal to apply either an Atomic or Atomic_Components
pragma to an object or type if the implementation cannot support the
indivisible reads and updates required by the pragma (see below).
11 It is illegal to specify the Size attribute of an atomic object, the
Component_Size attribute for an array type with atomic components, or the
layout attributes of an atomic component, in a way that prevents the
implementation from performing the required indivisible reads and updates.
12 If an atomic object is passed as a parameter, then the type of the formal
parameter shall either be atomic or allow pass by copy [(that is, not be a
nonatomic by-reference type)]. If an atomic object is used as an actual for a
generic formal object of mode in out, then the type of the generic formal
object shall be atomic. If the prefix of an attribute_reference for an Access
attribute denotes an atomic object [(including a component)], then the
designated type of the resulting access type shall be atomic. If an atomic
type is used as an actual for a generic formal derived type, then the ancestor
of the formal type shall be atomic or allow pass by copy. Corresponding rules
apply to volatile objects and types.
13 If a pragma Volatile, Volatile_Components, Atomic, or Atomic_Components
applies to a stand-alone constant object, then a pragma Import shall also
apply to it.
13.a Ramification: Hence, no initialization expression is allowed for
such a constant. Note that a constant that is atomic or volatile
because of its type is allowed.
13.b Reason: Stand-alone constants that are explicitly specified as
Atomic or Volatile only make sense if they are being manipulated
outside the Ada program. From the Ada perspective the object is
read-only. Nevertheless, if imported and atomic or volatile, the
implementation should presume it might be altered externally. For
an imported stand-alone constant that is not atomic or volatile,
the implementation can assume that it will not be altered.
Static Semantics
14 {representation pragma (Atomic) [partial]}
{pragma, representation (Atomic) [partial]} {representation pragma (Volatile)
[partial]} {pragma, representation (Volatile) [partial]}
{representation pragma (Atomic_Components) [partial]}
{pragma, representation (Atomic_Components) [partial]}
{representation pragma (Volatile_Components) [partial]}
{pragma, representation (Volatile_Components) [partial]} These pragmas are
representation pragmas (see 13.1).
Dynamic Semantics
15 For an atomic object (including an atomic component) all reads and updates
of the object as a whole are indivisible.
16 For a volatile object all reads and updates of the object as a whole are
performed directly to memory.
16.a Implementation Note: This precludes any use of register
temporaries, caches, and other similar optimizations for that
object.
17 {sequential (actions)} Two actions are sequential (see 9.10) if each is
the read or update of the same atomic object.
18 {by-reference type (atomic or volatile) [partial]} If a type is atomic or
volatile and it is not a by-copy type, then the type is defined to be a
by-reference type. If any subcomponent of a type is atomic or volatile, then
the type is defined to be a by-reference type.
19 If an actual parameter is atomic or volatile, and the corresponding formal
parameter is not, then the parameter is passed by copy.
19.a Implementation Note: Note that in the case where such a parameter
is normally passed by reference, a copy of the actual will have to
be produced at the call-site, and a pointer to the copy passed to
the formal parameter. If the actual is atomic, any copying has to
use indivisible read on the way in, and indivisible write on the
way out.
19.b Reason: It has to be known at compile time whether an atomic or a
volatile parameter is to be passed by copy or by reference. For
some types, it is unspecified whether parameters are passed by
copy or by reference. The above rules further specify the
parameter passing rules involving atomic and volatile types and
objects.
Implementation Requirements
20 {external effect (volatile/atomic objects) [partial]} The external effect
of a program (see 1.1.3) is defined to include each read and update of a
volatile or atomic object. The implementation shall not generate any memory
reads or updates of atomic or volatile objects other than those specified by
the program.
20.a Discussion: The presumption is that volatile or atomic objects
might reside in an "active" part of the address space where each
read has a potential side-effect, and at the very least might
deliver a different value.
20.b The rule above and the definition of external effect are intended
to prevent (at least) the following incorrect optimizations, where
V is a volatile variable:
20.c * X:= V; Y:=V; cannot be allowed to be translated as Y:=V; X:=V;
20.d * Deleting redundant loads: X:= V; X:= V; shall read the value
of V from memory twice.
20.e * Deleting redundant stores: V:= X; V:= X; shall write into V
twice.
20.f * Extra stores: V:= X+Y; should not translate to something like
V:= X; V:= V+Y;
20.g * Extra loads: X:= V; Y:= X+Z; X:=X+B; should not translate to
something like Y:= V+Z; X:= V+B;
20.h * Reordering of loads from volatile variables: X:= V1; Y:= V2;
(whether or not V1 = V2) should not translate to Y:= V2; X:=
V1;
20.i * Reordering of stores to volatile variables: V1:= X; V2:= X;
should not translate to V2:=X; V1:= X;
21 If a pragma Pack applies to a type any of whose subcomponents are atomic,
the implementation shall not pack the atomic subcomponents more tightly than
that for which it can support indivisible reads and updates.
21.a Implementation Note: A warning might be appropriate if no packing
whatsoever can be achieved.
Implementation Advice
22/2 {AI95-00259-01} A load or store of a volatile object whose size is a
multiple of System.Storage_Unit and whose alignment is nonzero, should be
implemented by accessing exactly the bits of the object and no others.
22.a/2 Implementation Advice: A load or store of a volatile object whose
size is a multiple of System.Storage_Unit and whose alignment is
nonzero, should be implemented by accessing exactly the bits of
the object and no others.
22.b/2 Reason: Since any object can be a volatile object, including
packed array components and bit-mapped record components, we
require the above only when it is reasonable to assume that the
machine can avoid accessing bits outside of the object.
22.c/2 Ramification: This implies that the load or store of a volatile
object that meets the above requirement should not be combined
with that of any other object, nor should it access any bits not
belonging to any other object. This means that the suitability of
the implementation for memory-mapped I/O can be determined from
its documentation, as any cases where the implementation does not
follow Implementation Advice must be documented.
23/2 {AI95-00259-01} A load or store of an atomic object should, where
possible, be implemented by a single load or store instruction.
23.a/2 Implementation Advice: A load or store of an atomic object should
be implemented by a single load or store instruction.
NOTES
24 9 An imported volatile or atomic constant behaves as a constant (i.e.
read-only) with respect to other parts of the Ada program, but can
still be modified by an "external source."
Incompatibilities With Ada 83
24.a {incompatibilities with Ada 83} Pragma Atomic replaces Ada 83's
pragma Shared. The name "Shared" was confusing, because the pragma
was not used to mark variables as shared.
Wording Changes from Ada 95
24.b/2 {AI95-00259-01} Added Implementation Advice to clarify the meaning
of Atomic and Volatile in machine terms. The documentation that
this advice applies will make the use of Ada implementations more
predictable for low-level (such as device register) programming.
24.c/2 {AI95-00272-01} Added wording to clarify that a slice of an object
of an atomic type is not atomic, just like a component of an
atomic type is not (necessarily) atomic.
C.7 Task Information
1/2 {AI95-00266-02} [This clause describes operations and attributes that can
be used to obtain the identity of a task. In addition, a package that
associates user-defined information with a task is defined. Finally, a package
that associates termination procedures with a task or set of tasks is
defined.]
Wording Changes from Ada 95
1.a/2 {AI95-00266-02} The title and text here were updated to reflect
the addition of task termination procedures to this clause.
C.7.1 The Package Task_Identification
Static Semantics
1 The following language-defined library package exists:
2/2 {AI95-00362-01} package Ada.Task_Identification is
pragma Preelaborate(Task_Identification);
type Task_Id is private;
pragma Preelaborable_Initialization (Task_Id);
Null_Task_Id : constant Task_Id;
function "=" (Left, Right : Task_Id) return Boolean;
3/1 {8652/0070} {AI95-00101-01} function Image
(T : Task_Id) return String;
function Current_Task return Task_Id;
procedure Abort_Task (T : in Task_Id);
4 function Is_Terminated(T : Task_Id) return Boolean;
function Is_Callable (T : Task_Id) return Boolean;
private
... -- not specified by the language
end Ada.Task_Identification;
Dynamic Semantics
5 A value of the type Task_Id identifies an existent task. The constant
Null_Task_Id does not identify any task. Each object of the type Task_Id is
default initialized to the value of Null_Task_Id.
6 The function "=" returns True if and only if Left and Right identify the
same task or both have the value Null_Task_Id.
7 The function Image returns an implementation-defined string that
identifies T. If T equals Null_Task_Id, Image returns an empty string.
7.a Implementation defined: The result of the
Task_Identification.Image attribute.
8 The function Current_Task returns a value that identifies the calling task.
9 The effect of Abort_Task is the same as the abort_statement for the task
identified by T. [In addition, if T identifies the environment task, the
entire partition is aborted, See E.1.]
10 The functions Is_Terminated and Is_Callable return the value of the
corresponding attribute of the task identified by T.
10.a.1/1 Ramification: {8652/0115} {AI95-00206-01} These routines can be
called with an argument identifying the environment task.
Is_Terminated will always be False for such a call, but
Is_Callable (usually True) could be False if the environment task
is waiting for the termination of dependent tasks. Thus, a
dependent task can use Is_Callable to determine if the main
subprogram has completed.
11 For a prefix T that is of a task type [(after any implicit dereference)],
the following attribute is defined:
12 T'Identity Yields a value of the type Task_Id that identifies the task
denoted by T.
13 For a prefix E that denotes an entry_declaration, the following attribute
is defined:
14 E'Caller Yields a value of the type Task_Id that identifies the task
whose call is now being serviced. Use of this attribute is
allowed only inside an entry_body or accept_statement
corresponding to the entry_declaration denoted by E.
15 {Program_Error (raised by failure of run-time check)} Program_Error is
raised if a value of Null_Task_Id is passed as a parameter to Abort_Task,
Is_Terminated, and Is_Callable.
16 {potentially blocking operation (Abort_Task) [partial]}
{blocking, potentially (Abort_Task) [partial]} Abort_Task is a potentially
blocking operation (see 9.5.1).
Bounded (Run-Time) Errors
17/2 {AI95-00237-01} {bounded error (cause) [partial]} It is a bounded error
to call the Current_Task function from an entry body, interrupt handler, or
finalization of a task attribute.
{Program_Error (raised by failure of run-time check)} Program_Error is raised,
or an implementation-defined value of the type Task_Id is returned.
17.a/2 Implementation defined: The value of Current_Task when in a
protected entry, interrupt handler, or finalization of a task
attribute.
17.b Implementation Note: This value could be Null_Task_Id, or the ID
of some user task, or that of an internal task created by the
implementation.
17.c/2 Ramification: {AI95-00237-01} An entry barrier is syntactically
part of an entry_body, so a call to Current_Task from an entry
barrier is also covered by this rule.
Erroneous Execution
18 {erroneous execution (cause) [partial]} If a value of Task_Id is passed as
a parameter to any of the operations declared in this package (or any
language-defined child of this package), and the corresponding task object no
longer exists, the execution of the program is erroneous.
Documentation Requirements
19 The implementation shall document the effect of calling Current_Task from
an entry body or interrupt handler.
19.a/2 This paragraph was deleted.
19.b/2 Documentation Requirement: The effect of calling Current_Task from
an entry body or interrupt handler.
NOTES
20 10 This package is intended for use in writing user-defined task
scheduling packages and constructing server tasks. Current_Task can be
used in conjunction with other operations requiring a task as an
argument such as Set_Priority (see D.5).
21 11 The function Current_Task and the attribute Caller can return a
Task_Id value that identifies the environment task.
Extensions to Ada 95
21.a/2 {AI95-00362-01} Task_Identification is now preelaborated, so it
can be used in preelaborated units.
Wording Changes from Ada 95
21.b/2 {8652/0070} {AI95-00101-01} Corrigendum: Corrected the mode of the
parameter to Abort_Task to in.
21.c/2 {AI95-00237-01} Corrected the wording to include finalization of a
task attribute in the bounded error case; we don't want to specify
which task does these operations.
C.7.2 The Package Task_Attributes
Static Semantics
1 The following language-defined generic library package exists:
2 with Ada.Task_Identification; use Ada.Task_Identification;
generic
type Attribute is private;
Initial_Value : in Attribute;
package Ada.Task_Attributes is
3 type Attribute_Handle is access all Attribute;
4 function Value(T : Task_Id := Current_Task)
return Attribute;
5 function Reference(T : Task_Id := Current_Task)
return Attribute_Handle;
6 procedure Set_Value(Val : in Attribute;
T : in Task_Id := Current_Task);
procedure Reinitialize(T : in Task_Id := Current_Task);
7 end Ada.Task_Attributes;
Dynamic Semantics
8 When an instance of Task_Attributes is elaborated in a given active
partition, an object of the actual type corresponding to the formal type
Attribute is implicitly created for each task (of that partition) that exists
and is not yet terminated. This object acts as a user-defined attribute of the
task. A task created previously in the partition and not yet terminated has
this attribute from that point on. Each task subsequently created in the
partition will have this attribute when created. In all these cases, the
initial value of the given attribute is Initial_Value.
9 The Value operation returns the value of the corresponding attribute of T.
10 The Reference operation returns an access value that designates the
corresponding attribute of T.
11 The Set_Value operation performs any finalization on the old value of the
attribute of T and assigns Val to that attribute (see 5.2 and 7.6).
12 The effect of the Reinitialize operation is the same as Set_Value where
the Val parameter is replaced with Initial_Value.
12.a Implementation Note: In most cases, the attribute memory can be
reclaimed at this point.
13 {Tasking_Error (raised by failure of run-time check)} For all the
operations declared in this package, Tasking_Error is raised if the task
identified by T is terminated.
{Program_Error (raised by failure of run-time check)} Program_Error is raised
if the value of T is Null_Task_Id.
13.1/2 {AI95-00237-01} After a task has terminated, all of its attributes are
finalized, unless they have been finalized earlier. When the master of an
instantiation of Ada.Task_Attributes is finalized, the corresponding attribute
of each task is finalized, unless it has been finalized earlier.
13.a/2 Reason: This is necessary so that a task attribute does not
outlive its type. For instance, that's possible if the
instantiation is nested, and the attribute is on a library-level
task.
13.b/2 Ramification: The task owning an attribute cannot, in general,
finalize that attribute. That's because the attributes are
finalized after the task is terminated; moreover, a task may have
attributes as soon as it is created; the task may never even have
been activated.
Bounded (Run-Time) Errors
13.2/1 {8652/0071} {AI95-00165-01} {bounded error (cause) [partial]} If the
package Ada.Task_Attributes is instantiated with a controlled type and the
controlled type has user-defined Adjust or Finalize operations that in turn
access task attributes by any of the above operations, then a call of
Set_Value of the instantiated package constitutes a bounded error. The call
may perform as expected or may result in forever blocking the calling task and
subsequently some or all tasks of the partition.
Erroneous Execution
14 {erroneous execution (cause) [partial]} It is erroneous to dereference the
access value returned by a given call on Reference after a subsequent call on
Reinitialize for the same task attribute, or after the associated task
terminates.
14.a Reason: This allows the storage to be reclaimed for the object
associated with an attribute upon Reinitialize or task
termination.
15 {erroneous execution (cause) [partial]} If a value of Task_Id is passed as
a parameter to any of the operations declared in this package and the
corresponding task object no longer exists, the execution of the program is
erroneous.
15.1/2 {8652/0071} {AI95-00165-01} {AI95-00237-01}
{erroneous execution (cause) [partial]} An access to a task attribute via a
value of type Attribute_Handle is erroneous if executed concurrently with
another such access or a call of any of the operations declared in package
Task_Attributes. An access to a task attribute is erroneous if executed
concurrently with or after the finalization of the task attribute.
15.a.1/1 Reason: There is no requirement of atomicity on accesses via a
value of type Attribute_Handle.
15.a.2/2 Ramification: A task attribute can only be accessed after
finalization through a value of type Attribute_Handle. Operations
in package Task_Attributes cannot be used to access a task
attribute after finalization, because either the master of the
instance has been or is in the process of being left (in which
case the instance is out of scope and thus cannot be called), or
the associated task is already terminated (in which case
Tasking_Error is raised for any attempt to call a task attribute
operation).
Implementation Requirements
16/1 {8652/0071} {AI95-00165-01} For a given attribute of a given task, the
implementation shall perform the operations declared in this package
atomically with respect to any of these operations of the same attribute of
the same task. The granularity of any locking mechanism necessary to achieve
such atomicity is implementation defined.
16.a.1/1 Implementation defined: Granularity of locking for Task_Attributes.
16.a Ramification: Hence, other than by dereferencing an access value
returned by Reference, an attribute of a given task can be safely
read and updated concurrently by multiple tasks.
17/2 {AI95-00237-01} After task attributes are finalized, the implementation
shall reclaim any storage associated with the attributes.
Documentation Requirements
18 The implementation shall document the limit on the number of attributes
per task, if any, and the limit on the total storage for attribute values per
task, if such a limit exists.
19 In addition, if these limits can be configured, the implementation shall
document how to configure them.
19.a/2 This paragraph was deleted.
19.b/2 Documentation Requirement: For package Task_Attributes, limits on
the number and size of task attributes, and how to configure any
limits.
Metrics
20/2 {AI95-00434-01} The implementation shall document the following metrics:
A task calling the following subprograms shall execute at a sufficiently high
priority as to not be preempted during the measurement period. This period
shall start just before issuing the call and end just after the call
completes. If the attributes of task T are accessed by the measurement tests,
no other task shall access attributes of that task during the measurement
period. For all measurements described here, the Attribute type shall be a
scalar type whose size is equal to the size of the predefined type Integer.
For each measurement, two cases shall be documented: one where the accessed
attributes are of the calling task [(that is, the default value for the T
parameter is used)], and the other, where T identifies another,
non-terminated, task.
21 The following calls (to subprograms in the Task_Attributes package) shall
be measured:
22 * a call to Value, where the return value is Initial_Value;
23 * a call to Value, where the return value is not equal to Initial_Value;
24 * a call to Reference, where the return value designates a value equal
to Initial_Value;
25 * a call to Reference, where the return value designates a value not
equal to Initial_Value;
26/2 * {AI95-00434-01} a call to Set_Value where the Val parameter is not
equal to Initial_Value and the old attribute value is equal to
Initial_Value;
27 * a call to Set_Value where the Val parameter is not equal to
Initial_Value and the old attribute value is not equal to
Initial_Value.
27.a/2 Documentation Requirement: The metrics for the Task_Attributes
package.
Implementation Permissions
28 An implementation need not actually create the object corresponding to a
task attribute until its value is set to something other than that of
Initial_Value, or until Reference is called for the task attribute. Similarly,
when the value of the attribute is to be reinitialized to that of
Initial_Value, the object may instead be finalized and its storage reclaimed,
to be recreated when needed later. While the object does not exist, the
function Value may simply return Initial_Value, rather than implicitly
creating the object.
28.a Discussion: The effect of this permission can only be observed if
the assignment operation for the corresponding type has
side-effects.
28.b/2 Implementation Note: {AI95-00114-01} This permission means that
even though every task has every attribute, storage need only be
allocated for those attributes for which function Reference has
been invoked or set to a value other than that of Initial_Value.
29 An implementation is allowed to place restrictions on the maximum number
of attributes a task may have, the maximum size of each attribute, and the
total storage size allocated for all the attributes of a task.
Implementation Advice
30/2 {AI95-00434-01} Some implementations are targeted to domains in which
memory use at run time must be completely deterministic. For such
implementations, it is recommended that the storage for task attributes will
be pre-allocated statically and not from the heap. This can be accomplished by
either placing restrictions on the number and the size of the attributes of a
task, or by using the pre-allocated storage for the first N attribute objects,
and the heap for the others. In the latter case, N should be documented.
30.a/2 Implementation Advice: If the target domain requires deterministic
memory use at run time, storage for task attributes should be
pre-allocated statically and the number of attributes
pre-allocated should be documented.
30.b/2 Discussion: We don't mention "restrictions on the size and
number" (that is, limits) in the text for the Annex, because it is
covered by the Documentation Requirement above, and we try not to
repeat requirements in the Annex (they're enough work to meet
without having to do things twice).
30.1/2 {AI95-00237-01} Finalization of task attributes and reclamation of
associated storage should be performed as soon as possible after task
termination.
30.c/2 Implementation Advice: Finalization of task attributes and
reclamation of associated storage should be performed as soon as
possible after task termination.
30.d/2 Reason: {AI95-00237-01} This is necessary because the normative
wording only says that attributes are finalized "after" task
termination. Without this advice, waiting until the instance is
finalized would meet the requirements (it is after termination,
but may be a very long time after termination). We can't say
anything more specific than this, as we do not want to require the
overhead of an interaction with the tasking system to be done at a
specific point.
NOTES
31 12 An attribute always exists (after instantiation), and has the
initial value. It need not occupy memory until the first operation
that potentially changes the attribute value. The same holds true
after Reinitialize.
32 13 The result of the Reference function should be used with care; it
is always safe to use that result in the task body whose attribute is
being accessed. However, when the result is being used by another
task, the programmer must make sure that the task whose attribute is
being accessed is not yet terminated. Failing to do so could make the
program execution erroneous.
33/2 This paragraph was deleted.{AI95-00434-01}
Wording Changes from Ada 95
33.a/2 {8652/0071} {AI95-00165-01} Corrigendum: Clarified that use of
task attribute operations from within a task attribute operation
(by an Adjust or Finalize call) is a bounded error, and that
concurrent use of attribute handles is erroneous.
33.b/2 {AI95-00237-01} Clarified the wording so that the finalization
takes place after the termination of the task or when the instance
is finalized (whichever is sooner).
C.7.3 The Package Task_Termination
Static Semantics
1/2 {AI95-00266-02} The following language-defined library package exists:
2/2 with Ada.Task_Identification;
with Ada.Exceptions;
package Ada.Task_Termination is
pragma Preelaborate(Task_Termination);
3/2 type Cause_Of_Termination
is (Normal, Abnormal, Unhandled_Exception);
4/2 type Termination_Handler is access protected procedure
(Cause : in Cause_Of_Termination;
T : in Ada.Task_Identification.Task_Id;
X : in Ada.Exceptions.Exception_Occurrence);
5/2 procedure Set_Dependents_Fallback_Handler
(Handler: in Termination_Handler);
function Current_Task_Fallback_Handler return Termination_Handler;
6/2 procedure Set_Specific_Handler
(T : in Ada.Task_Identification.Task_Id;
Handler : in Termination_Handler);
function Specific_Handler (T : Ada.Task_Identification.Task_Id)
return Termination_Handler;
7/2 end Ada.Task_Termination;
Dynamic Semantics
8/2 {AI95-00266-02} {termination handler} {handler (termination)} The type
Termination_Handler identifies a protected procedure to be executed by the
implementation when a task terminates. Such a protected procedure is called a
handler. In all cases T identifies the task that is terminating. If the task
terminates due to completing the last statement of its body, or as a result of
waiting on a terminate alternative, then Cause is set to Normal and X is set
to Null_Occurrence. If the task terminates because it is being aborted, then
Cause is set to Abnormal and X is set to Null_Occurrence. If the task
terminates because of an exception raised by the execution of its task_body,
then Cause is set to Unhandled_Exception and X is set to the associated
exception occurrence.
9/2 {AI95-00266-02} {fall-back handler} {termination handler (fall-back)}
{specific handler} {termination handler (specific)}
{set (termination handler)} {cleared (termination handler)} Each task has two
termination handlers, a fall-back handler and a specific handler. The specific
handler applies only to the task itself, while the fall-back handler applies
only to the dependent tasks of the task. A handler is said to be set if it is
associated with a non-null value of type Termination_Handler, and cleared
otherwise. When a task is created, its specific handler and fall-back handler
are cleared.
10/2 {AI95-00266-02} The procedure Set_Dependents_Fallback_Handler changes the
fall-back handler for the calling task; if Handler is null, that fall-back
handler is cleared, otherwise it is set to be Handler.all. If a fall-back
handler had previously been set it is replaced.
11/2 {AI95-00266-02} The function Current_Task_Fallback_Handler returns the
fall-back handler that is currently set for the calling task, if one is set;
otherwise it returns null.
12/2 {AI95-00266-02} The procedure Set_Specific_Handler changes the specific
handler for the task identified by T; if Handler is null, that specific
handler is cleared, otherwise it is set to be Handler.all. If a specific
handler had previously been set it is replaced.
13/2 {AI95-00266-02} The function Specific_Handler returns the specific
handler that is currently set for the task identified by T, if one is set;
otherwise it returns null.
14/2 {AI95-00266-02} As part of the finalization of a task_body, after
performing the actions specified in 7.6 for finalization of a master, the
specific handler for the task, if one is set, is executed. If the specific
handler is cleared, a search for a fall-back handler proceeds by recursively
following the master relationship for the task. If a task is found whose
fall-back handler is set, that handler is executed; otherwise, no handler is
executed.
15/2 {AI95-00266-02} For Set_Specific_Handler or Specific_Handler,
Tasking_Error is raised if the task identified by T has already terminated.
Program_Error is raised if the value of T is
Ada.Task_Identification.Null_Task_Id.
16/2 {AI95-00266-02} An exception propagated from a handler that is invoked as
part of the termination of a task has no effect.
Erroneous Execution
17/2 {AI95-00266-02} For a call of Set_Specific_Handler or Specific_Handler,
if the task identified by T no longer exists, the execution of the program is
erroneous.
Extensions to Ada 95
17.a/2 {AI95-00266-02} {extensions to Ada 95} Package Task_Termination is
new.
Generated by dwww version 1.15 on Sat May 18 06:00:03 CEST 2024.