Version 1.1 of ais/ai-00265.txt

Unformatted version of ais/ai-00265.txt version 1.1
Other versions for file ais/ai-00265.txt

!standard D.2.2 (5)          01-05-10 AI95-00265/01
!standard D.7 (00)
!class amendment 01-05-10
!status work item 01-05-10
!status received 01-05-10
!priority High
!difficulty Medium
!subject Task Activation Policy for High-Integrity Systems
!summary
A configuration pragma is proposed to select the task activation policy. This is in response to certification concerns about hazardous race conditions that could occur due to tasks being activated prior to completion of the library-level elaboration code.
!problem
There are determinism and hazard mitigation issues relating to task activation semantics for Safety-Critical and High-Integrity applications.
!proposal
To satisfy the requirements of the Safety Critical and High-Integrity domains, there is a need to define the behavior of program elaboration to be atomic; that is, no interrupts are delivered and task activation shall be deferred until the completion of all library-level elaboration code. This eliminates all hazards that relate to tasks and interrupt handlers accessing global data prior to it having been elaborated, without having to resort to potentially complex elaboration order control. In some cases, it may be that the correct sequential elaboration order of the library units conflicts with an order that would need to be imposed to allow a task to use fully-elaborated global data as part of execution of its elaboration code.
A proposed approach to addressing this concern is to introduce a configuration pragma that defines the task activation policy. This pragma is considered independently of the Ravenscar Profile definition since this dynamic behavior is optional rather than mandated by the Profile. In addition, it may be required by programs that do not use the Ravenscar Profile.
The policy is selected by configuration pragma Task_Activation_Policy. Two policy identifiers are defined by the Standard : Deferred and Standard. The default policy is Standard.
!wording
Static Semantics
pragma Task_Activation_Policy ( <policy_identifier> );
Dynamic Semantics
Task_Activation_Policy => Standard
With the Standard value as the task activation policy, the execution of the declarative part of the Environment task is as defined by the standard mode of operation with respect to task activation and interrupt handler attachment.
Task_Activation_Policy => Deferred
With the Deferred value as the task activation policy, all task activation for library-level tasks, and all interrupt handler attachment for library-level interrupt handlers is deferred. The deferred task activation and handler attachment occurs immediately after the "begin" of the Environment task. At this point, the Environment task is suspended until all deferred task activation and handler attachment is complete.
In this mode of operation, it is a bounded error for the Environment task to execute a potentially-blocking operation other than a delay statement during its declarative part. Program_Error may be raised by the call, or the active partition may deadlock.
In this mode of operation, it is a bounded error for any deferred task activation to fail. The Environment task and all tasks whose activations fail are terminated. A task whose activation succeeds may continue to execute, or may instead become immediately terminated, thereby completing execution of the active partition.
Implementation Advice
For a Task_Activation_Policy of Deferred, if the Environment task executes a (permanently) blocking operation during its declarative part (prior to activation of tasks and enabling of delivery of interrupts) then it is recommended that the active partition be immediately terminated. However, detection of this case may introduce distributed overhead in the runtime execution, and so it is not mandated.
If any deferred task activation fails, it is recommended that the active partition be immediately terminated to mitigate the hazard posed by continuing execution with a subset of the tasks being active. However, detection of this case may introduce distributed overhead in the runtime execution, and so it is not mandated.
!example
!discussion
!ACATS test
!appendix

[Editor's note: This originally was part of the Ravenscar proposal,
see AI-249.]

****************************************************************

Questions? Ask the ACAA Technical Agent