Annex C (normative) Systems Programming 1 [ 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 This Annex is new to Ada 95. C.1 Access to Machine Operations 1/3 {AI05-0299-1} [This subclause specifies rules regarding access to machine instructions from within an Ada program.] 1.a/2 Implementation defined: Implementation-defined intrinsic subprograms. Implementation Requirements 2 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/3 {AI05-0229-1} The support for interfacing aspects (see Annex B) should include 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/3 {AI05-0229-1} The implementation shall document the subprogram calling conventions associated with the convention identifiers available for use with the Convention aspect (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/3 {AI95-00434-01} {AI05-0299-1} This subclause specifies minimal requirements on the support for representation items and related features. Implementation Requirements 2/3 {AI05-0299-1} The implementation shall support at least the functionality defined by the recommended levels of support in Clause 13. C.3 Interrupt Support 1/3 {AI05-0299-1} [This subclause 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 nonreserved 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 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 nonreserved 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/3 {AI95-00434-01} {AI05-0299-1} 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/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 Paragraphs 1 through 6 were moved to Annex J, "Obsolescent Features". Static Semantics 6.1/3 {AI05-0229-1} For a parameterless protected procedure, the following language-defined representation aspects may be specified: 6.2/3 Interrupt_Handler The type of aspect Interrupt_Handler is Boolean. If directly specified, the aspect_definition shall be a static expression. [This aspect is never inherited;] if not directly specified, the aspect is False. 6.a/3 Aspect Description for Interrupt_Handler: Protected procedure may be attached to interrupts. 6.3/3 Attach_Handler The aspect Attach_Handler is an expression, which shall be of type Interrupts.Interrupt_Id. [This aspect is never inherited.] 6.b/3 Aspect Description for Attach_Handler: Protected procedure is attached to an interrupt. Legality Rules 7/3 {AI95-00434-01} {AI05-0033-1} {AI05-0229-1} If either the Attach_Handler or Interrupt_Handler aspect are specified for a protected procedure, the corresponding protected_type_declaration or single_protected_declaration shall be a library-level declaration and shall not be declared within a generic body. In addition to the places where Legality Rules normally apply (see 12.3), this rule also applies in the private part of an instance of a generic unit. 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. 7.b/3 {AI05-0033-1} {AI05-0229-1} We cannot allow these aspects in protected declarations in a generic body, because legality rules are not checked for instance bodies, and these should not be allowed if the instance is not at the library level. The protected types can be declared in the private part if this is desired. Note that while the 'Access to use the handler would provide the check in the case of Interrupt_Handler, there is no other check for Attach_Handler. Since these aspects are so similar, we want the rules to be the same. 8/3 This paragraph was deleted.{AI95-00253-01} {AI95-00303-01} {AI05-0033-1} Dynamic Semantics 9/3 {AI05-0229-1} If the Interrupt_Handler aspect of a protected procedure is True, then the procedure may be attached dynamically, as a handler, to interrupts (see C.3.2). [Such procedures are allowed to be attached to multiple interrupts.] 10/3 {AI05-0229-1} The expression specified for the Attach_Handler aspect of a protected procedure P is evaluated as part of the creation of the protected object that contains P. The value of the expression identifies an interrupt. As part of the initialization of that object, P (the handler procedure) is attached to the identified interrupt. A check is made that the corresponding interrupt is not reserved. Program_Error is raised if the check fails, and the existing treatment for the interrupt is not affected. 11/3 {AI95-00434-01} {AI05-0229-1} If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object that contains a protected procedure for which either the Attach_Handler aspect is specified or the Interrupt_Handler aspect is True, a check is made that the initial ceiling priority of the object is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised. 12/3 {8652/0068} {AI95-00121-01} {AI05-0229-1} 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 the Attach_Handler aspect was specified 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/3 Discussion: {8652/0068} {AI95-00121-01} {AI95-00303-01} {AI05-0229-1} 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 procedures with an Attach_Handler aspect specified 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 aspect 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 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/3 {8652/0068} {AI95-00121-01} {AI05-0229-1} If the handlers for a given interrupt attached via aspect 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 aspect 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/3 Discussion: {8652/0068} {AI95-00121-01} {AI05-0229-1} This simplifies implementation of the Attach_Handler aspect 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/3 {AI05-0229-1} When the aspects Attach_Handler or Interrupt_Handler are specified for 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/3 Implementation defined: Any restrictions on a protected procedure or its containing type when an aspect Attach_handler or Interrupt_Handler is specified. 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/3 {AI05-0229-1} Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler aspects are allowed to be used for other, implementation defined, forms of interrupt handlers. 19.a/3 Ramification: {AI05-0229-1} For example, if an implementation wishes to allow interrupt handlers to have parameters, it is allowed to do so via these aspects; it need not invent implementation-defined aspects for the purpose. 19.b/3 Implementation defined: Any other forms of interrupt handler supported by the Attach_Handler and Interrupt_Handler aspects. 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/3 4 {AI05-0229-1} The Attach_Handler aspect may 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} 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. Extensions to Ada 2005 25.d/3 {AI05-0229-1} Aspects Interrupt_Handler and Attach_Handler are new; pragmas Interrupt_Handler and Attach_Handler are now obsolescent. Wording Changes from Ada 2005 25.e/3 {AI05-0033-1} Correction: Added missing generic contract wording for the aspects Attach_Handler and Interrupt_Handler. C.3.2 The Package Interrupts Static Semantics 1 The following language-defined packages exist: 2/3 {AI05-0167-1} with System; with System.Multiprocessors; 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; 10.1/3 {AI05-0167-1} function Get_CPU (Interrupt : Interrupt_Id) return System.Multiprocessors.CPU_Range; 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/3 {AI05-0229-1} 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. If New_Handler designates a protected procedure for which the aspect Interrupt_Handler is False, 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 is raised if this check fails. 21/3 {AI05-0229-1} 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 aspect Attach_Handler), the handler is not detached and Program_Error is raised. 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. 22.1/3 {AI05-0153-3} The function Get_CPU returns the processor on which the handler for Interrupt is executed. If the handler can execute on more than one processor the value System.Multiprocessors.Not_A_Specific_CPU is returned. 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/3 {AI95-00434-01} {AI05-0229-1} 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 a protected procedure that specifies either the Attach_Handler or Interrupt_Handler aspects, but does not specify the Interrupt_Priority aspect. [This default need not be the same for all interrupts.] 24.a.1/3 Documentation Requirement: If the Ceiling_Locking policy is in effect, the default ceiling priority for a protected object that specifies an interrupt handler aspect. 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/3 {AI05-0229-1} Device_Priority : constant array (1..5) of System.Interrupt_Priority := ( ... ); protected type Device_Interface (Int_Id : Ada.Interrupts.Interrupt_Id) with Interrupt_Priority => Device_Priority(Int_Id) is procedure Handler with Attach_Handler => 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. Incompatibilities With Ada 2005 28.b/3 {AI05-0167-1} Function Get_CPU is added to Interrupts. If Interrupts is referenced in a use_clause, and an entity E with a defining_identifier of Get_CPU is defined in a package that is also referenced in a use_clause, the entity E may no longer be use-visible, resulting in errors. This should be rare and is easily fixed if it does occur. C.4 Preelaboration Requirements 1/3 {AI05-0299-1} [This subclause 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. 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 Aspect Discard_Names 1/4 {AI12-0072-1} [Specifying the aspect Discard_Names can be used to request a reduction in storage used for the names of entities with runtime name text.] Static Semantics 1.1/4 {AI12-0072-1} An entity with runtime name text is a nonderived enumeration first subtype, a tagged first subtype, or an exception. 1.2/4 {AI12-0072-1} For an entity with runtime name text, the following language-defined representation aspect may be specified: 1.3/4 Discard_Names The type of aspect Discard_Names is Boolean. If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False. 1.a.1/4 Aspect Description for Discard_Names: Requests a reduction in storage for names associated with an entity. 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. Legality Rules 5/4 {AI12-0072-1} The local_name (if present) shall denote an entity with runtime name text. The pragma specifies that the aspect Discard_Names for the type or exception has the value True. Without a local_name, the pragma specifies that all entities with runtime name text declared after the pragma, within the same declarative region have the value True for aspect Discard_Names. Alternatively, the pragma can be used as a configuration pragma. If the configuration pragma Discard_Names applies to a compilation unit, all entities with runtime name text declared in the compilation unit have the value True for the aspect Discard_Names.. 5.a/4 Ramification: {AI12-0072-1} If the aspect is specified for a type, then it is inherited by all descendants of the type. The aspect cannot be specified as False on a derived type (because specifying the aspect is not allowed on derived enumeration types, and by rule applying to all aspects for other types (see 13.1.1)). Static Semantics 6 If a local_name is given, then a pragma Discard_Names is a representation pragma. 6.a/4 This paragraph was deleted.{AI05-0229-1} {AI12-0072-1} 7/4 {AI95-00285-01} {AI95-00400-01} {AI12-0072-1} If the aspect Discard_Names is True for 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 aspect Discard_Names is True for 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 aspect Discard_Names is True for 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/4 Implementation defined: The semantics of some attributes and functions of an entity for which aspect Discard_Names is True. 7.b Ramification: The Width attribute is still defined in terms of Image. 7.c/4 {AI95-00285-01} {AI12-0072-1} The semantics of S'Wide_Wide_Image and S'Wide_Wide_Value are implementation defined for any subtype of an enumeration type for which the aspect is True. (The pragma, if used, actually names the first subtype, of course.) Implementation Advice 8/4 {AI12-0072-1} If the aspect Discard_Names is True for an entity, then the implementation should reduce the amount of storage used for storing names associated with that entity. 8.a/4 Implementation Advice: If aspect Discard_Names is True for 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. Aspect 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 when aspect Discard_Names is True 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 aspect. Implementations that are capable of avoiding the extra storage in cases where the Image attribute is never used might also wish to ignore the aspect. 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. Wording Changes from Ada 2012 8.f/4 {AI12-0072-1} Corrigendum: Defined the pragma in terms of the aspect Discard_Names, and added a missing definition of the meaning of the configuration pragma. This is not intended to make any semantic change (Ada 2012 has an aspect Discard_Names defined via blanket rules for representation pragmas in 13.1 and 13.1.1), just to clarify the meaning. C.6 Shared Variable Control 1/3 {AI05-0229-1} {AI05-0299-1} [This subclause defines representation aspects that control the use of shared variables.] Paragraphs 2 through 6 were moved to Annex J, "Obsolescent Features". Static Semantics 6.1/3 {AI05-0229-1} For an object_declaration, a component_declaration, or a full_type_declaration, the following representation aspects may be specified: 6.2/3 Atomic The type of aspect Atomic is Boolean. 6.a/3 Aspect Description for Atomic: Declare that a type, object, or component is atomic. 6.3/3 Independent The type of aspect Independent is Boolean. 6.b/3 Aspect Description for Independent: Declare that a type, object, or component is independently addressable. 6.4/3 Volatile The type of aspect Volatile is Boolean. 6.c/3 Aspect Description for Volatile: Declare that a type, object, or component is volatile. 6.5/3 {AI05-0229-1} For a full_type_declaration of an array type (including the anonymous type of an object_declaration of an anonymous array object), the following representation aspects may be specified: 6.6/3 Atomic_Components The type of aspect Atomic_Components is Boolean. 6.d/3 Aspect Description for Atomic_Components: Declare that the components of an array type or object are atomic. 6.7/3 Volatile_Components The type of aspect Volatile_Components is Boolean. 6.e/3 Aspect Description for Volatile_Components: Declare that the components of an array type or object are volatile. 6.8/3 {AI05-0229-1} For a full_type_declaration (including the anonymous type of an object_declaration of an anonymous array object), the following representation aspect may be specified: 6.9/3 Independent_Components The type of aspect Independent_Components is Boolean. 6.f/3 Aspect Description for Independent_Components: Declare that the components of an array or record type, or an array object, are independently addressable. 6.10/3 {AI05-0229-1} If any of these aspects are directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), each of these aspects is False. 7/3 {AI95-00272-01} {AI05-0229-1} An atomic type is one for which the aspect Atomic is True. An atomic object (including a component) is one for which the aspect Atomic is True, or a component of an array for which the aspect Atomic_Components is True for the associated type, 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/3 {AI05-0229-1} A volatile type is one for which the aspect Volatile is True. A volatile object (including a component) is one for which the aspect Volatile is True, or a component of an array for which the aspect Volatile_- Components is True for the associated type, 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)]. 8.1/4 {AI05-0009-1} {AI05-0229-1} {AI12-0001-1} When True, the aspects Independent and Independent_Components specify as independently addressable the named object or component(s), or in the case of a type, all objects or components of that type. All atomic objects and aliased objects are considered to be specified as independently addressable. 8.a/3 Ramification: If the compiler cannot guarantee that an object (including a component) for which aspect Independent or aspect Independent_Components is True is independently addressable from any other nonoverlapping object, then the aspect specification must be rejected. 8.b/3 Similarly, an atomic object (including atomic components) is always independently addressable from any other nonoverlapping object. Any representation item which would prevent this from being true should be rejected, notwithstanding what this Standard says elsewhere (specifically, in the Recommended Level of Support). Paragraph 9 was moved to Annex J, "Obsolescent Features". Legality Rules 9.1/3 {AI05-0229-1} If aspect Independent_Components is specified for a full_type_declaration, the declaration shall be that of an array or record type. 10/4 {AI05-0229-1} {AI12-0001-1} It is illegal to specify either of the aspects Atomic or Atomic_Components to have the value True for an object or type if the implementation cannot support the indivisible and independent reads and updates required by the aspect (see below). 11/4 {AI12-0001-1} 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 and independent reads and updates. 12/3 {AI05-0142-4} {AI05-0218-1} If an atomic object is passed as a parameter, then the formal parameter shall either have an atomic type or allow pass by copy. 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. Corresponding rules apply to volatile objects and types. 12.a/3 Ramification: {AI05-0142-4} A formal parameter allows pass by copy if it is not aliased and it is of a type that allows pass by copy (that is, is not a by-reference type). 12.1/3 {AI05-0218-1} If a volatile type is used as an actual for a generic formal array type, then the element type of the formal type shall be volatile. 13/3 {AI05-0229-1} If an aspect Volatile, Volatile_Components, Atomic, or Atomic_Components is directly specified to have the value True for a stand-alone constant object, then the aspect Import shall also be specified as True for 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. 13.c/3 To be honest: {AI05-0218-1} Volatile_Components and Atomic_Components actually are aspects of the anonymous array type; this rule only applies when the aspect is specified directly on the constant object and not when the (named) array type has the aspect. 13.1/3 {AI05-0009-1} {AI05-0229-1} It is illegal to specify the aspect Independent or Independent_Components as True for a component, object or type if the implementation cannot provide the independent addressability required by the aspect (see 9.10). 13.2/3 {AI05-0009-1} {AI05-0229-1} It is illegal to specify a representation aspect for a component, object or type for which the aspect Independent or Independent_Components is True, in a way that prevents the implementation from providing the independent addressability required by the aspect. Paragraph 14 was moved to Annex J, "Obsolescent Features". Dynamic Semantics 15 For an atomic object (including an atomic component) all reads and updates of the object as a whole are indivisible. 16/3 {AI05-0117-1} {AI05-0275-1} All tasks of the program (on all processors) that read or update volatile variables see the same order of updates to the variables. A use of an atomic variable or other mechanism may be necessary to avoid erroneous execution and to ensure that access to nonatomic volatile variables is sequential (see 9.10). 16.a/3 Implementation Note: {AI05-0117-1} {AI05-0275-1} To ensure this, on a multiprocessor, any read or update of an atomic object may require the use of an appropriate memory barrier. 16.b/3 Discussion: {AI05-0275-1} From 9.10 it follows that (in non-erroneous programs) accesses to variables, including those shared by multiple tasks, are always sequential. This guarantees that no task will ever see partial updates of any variable. For volatile variables (including atomic variables), the above rule additionally specifies that all tasks see the same order of updates. 16.c/3 {AI05-0275-1} If for a shared variable X, a read of X occurs sequentially after an update of X, then the read will return the updated value if X is volatile or atomic, but may or or may not return the updated value if X is nonvolatile. For nonvolatile accesses, a signaling action is needed in order to share the updated value. 16.d/3 {AI05-0275-1} Because accesses to the same atomic variable by different tasks establish a sequential order between the actions of those tasks, implementations may be required to emit memory barriers around such updates or use atomic instructions that imply such barriers. 17 Two actions are sequential (see 9.10) if each is the read or update of the same atomic object. 18 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 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/4 This paragraph was deleted.{AI05-0229-1} {AI12-0001-1} 21.a/4 This paragraph was deleted.{AI05-0009-1} {AI12-0001-1} 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." 25/4 10 {AI12-0001-1} Specifying the Pack aspect cannot override the effect of specifying an Atomic or Atomic_Components aspect. Incompatibilities With Ada 83 25.a 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 25.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. 25.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. Incompatibilities With Ada 2005 25.d/3 {AI05-0218-1} Correction: Plugged a hole involving volatile components of formal types when the formal type's component has a nonvolatile type. This was done by making certain actual types illegal for formal derived and formal array types; these types were allowed for Ada 95 and Ada 2005. Extensions to Ada 2005 25.e/3 {AI05-0009-1} {AI05-0229-1} Aspects Independent and Independent_Components are new; they eliminate ambiguity about independent addressability. 25.f/3 {AI05-0229-1} Aspects Atomic, Atomic_Components, Volatile, and Volatile_Components are new; pragmas Atomic, Atomic_Components, Volatile, and Volatile_Components are now obsolescent. Wording Changes from Ada 2005 25.g/3 {AI05-0117-1} {AI05-0275-1} Revised the definition of volatile to eliminate overspecification and simply focus on the root requirement (that all tasks see the same view of volatile objects). This is not an inconsistency; "memory" arguably includes on-chip caches so long as those are kept consistent. Moreover, it is difficult to imagine a program that could tell the difference. 25.h/3 {AI05-0142-4} Added wording to take explicitly aliased parameters (see 6.1) into account when determining the legality of parameter passing of volatile and atomic objects. Wording Changes from Ada 2012 25.i/4 {AI12-0001-1} Corrigendum: Clarified that aliased objects are considered to be specified as independently addressable, and also eliminated an unnecessary rule. C.7 Task Information 1/3 {AI95-00266-02} {AI05-0299-1} [This subclause 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/3 {AI95-00266-02} {AI05-0299-1} The title and text here were updated to reflect the addition of task termination procedures to this subclause. 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/3 {8652/0070} {AI95-00101-01} {AI05-0189-1} function Image (T : Task_Id) return String; function Current_Task return Task_Id; function Environment_Task return Task_Id; procedure Abort_Task (T : in Task_Id); 4/3 {AI05-0189-1} function Is_Terminated (T : Task_Id) return Boolean; function Is_Callable (T : Task_Id) return Boolean; function Activation_Is_Complete (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. 8.1/3 {AI05-0189-1} The function Environment_Task returns a value that identifies the environment 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. 10.1/3 {AI05-0189-1} The function Activation_Is_Complete returns True if the task identified by T has completed its activation (whether successfully or not). It returns False otherwise. If T identifies the environment task, Activation_Is_Complete returns True after the elaboration of the library_items of the partition 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/3 E'Caller {AI05-0262-1} 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 accept_statement, or entry_body after the entry_barrier, corresponding to the entry_declaration denoted by E. 15 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 Abort_Task is a potentially blocking operation (see 9.5.1). Bounded (Run-Time) Errors 17/3 {AI95-00237-01} {AI05-0004-1} 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 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 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 11 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 12 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. Incompatibilities With Ada 2005 21.d/3 {AI05-0189-1} Functions Environment_Task and Activation_Is_Complete are added to Task_Identification. If Task_Identification is referenced in a use_clause, and an entity E with a defining_identifier of Environment_Task or Activation_Is_Complete is defined in a package that is also referenced in a use_clause, the entity E may no longer be use-visible, resulting in errors. This should be rare and is easily fixed if it does occur. 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 For all the operations declared in this package, Tasking_Error is raised if the task identified by T is terminated. 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} 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 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 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} 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, nonterminated, 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 13 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 14 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. 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/3 {AI95-00266-02} {AI05-0202-1} 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, and the finalization of the task completes normally, 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; X is set to Null_Occurrence if the finalization of the task completes normally. If the task terminates because of an exception raised by the execution of its task_body, then Cause is set to Unhandled_Exception; X is set to the associated exception occurrence if the finalization of the task completes normally. Independent of how the task completes, if finalization of the task propagates an exception, then Cause is either Unhandled_Exception or Abnormal, and X is an exception occurrence that identifies the Program_Error exception. 9/2 {AI95-00266-02} 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 nonnull value of type Termination_Handler, and cleared otherwise. When a task is created, its specific handler and fall-back handler are cleared. 10/3 {AI95-00266-02} {AI05-0264-1} 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/3 {AI95-00266-02} {AI05-0264-1} 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/3 {AI95-00266-02} {AI05-0264-1} 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. 12.a/3 Ramification: {AI05-0005-1} This package cannot portably be used to set a handler on the program as a whole. It is possible to call Set_Specific_Handler with the environment task's ID. But any call to the handler would necessarily be a Bounded (Run-Time) Error, as the handler is called after the task's finalization has completed. In the case of the environment task, that includes any possible protected objects, and calling a protected object after it is finalized is a Bounded (Run-Time) Error (see 9.4). This might work in a particular implementation, but it cannot be depended upon. 13/3 {AI95-00266-02} {AI05-0264-1} 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} Package Task_Termination is new. Wording Changes from Ada 2005 17.b/3 {AI05-0202-1} Correction: Specified what is passed to the handler if the finalization of the task fails after it is completed. This was not specified at all in Ada 2005, so there is a possibility that some program depended on some other behavior of an implementation. But as this case is very unlikely (and only occurs when there is already a significant bug in the program - so should not occur in fielded systems), we're not listing this as an inconsistency.