!standard D.2.2 (5) 03-01-06 AI95-00265/04 !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 Partition Elaboration Policy for High-Integrity Systems !summary A configuration pragma is proposed to select the partition elaboration policy. This is in response to certification concerns about hazardous race conditions that could occur due to tasks being activated and interrupt handlers being executed prior to completion of the library-level elaboration code. !problem There are determinism and hazard mitigation issues relating to task activation and interrupt handler execution 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 to define the partition elaboration policy. The policy is selected by the configuration pragma Partition_Elaboration_Policy. Two policy identifiers are defined by the standard : Sequential and Concurrent. The default policy is Concurrent. If Sequential is chosen then Restriction No_Task_Hierarchy must also be specified. !wording New section H.6: H.6 Pragma Partition_Elaboration_Policy This clause defines a pragma for user control over elaboration policy. Syntax The form of a pragma Partition_Elaboration_Policy is as follows: pragma Partition_Elaboration_Policy ( ); The Policy_Identifier shall be either Sequential or Concurrent; Concurrent is the default. Legality Rules If the Sequential policy is specified for a partition then pragma Restrictions (No_Task_Hierarchy) shall also be specified for the partition. Post-Compilation Rules The pragma is a configuration pragma. It applies to all compilation units in a partition. Dynamic Semantics If the Policy_Identifier is Sequential, 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 after the elaboration of all library_items prior to calling the main subprogram. At this point the Environment task is suspended until all deferred task activation and handler attachment is complete. Task activation does not inherit the priority of the Environment task. If the Policy_Identifier is Sequential and the Environment task, in its elaboration of library_items, executes a potentially-blocking operation other than a delay statement, task creation or a call on a protected entry with a open barrier then it becomes terminated, thereby completing execution of the active partition. If any deferred task activation fails then Tasking_Error is raised in the Environment task. The Environment task and all tasks whose activations fail are terminated. If the Policy_Identifier is Concurrent the execution of the declarative part of the Environment task is as defined in 10.2. Implementation Advice 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. Implementation Permission If the Environment task becomes permanently blocked it should become terminated. However an implemention is allowed not to detect this state if it causes distributed overhead in the run-time. !example !discussion a) The Restriction No_Task_Hierarchy is needed to prevent deadlock. b) If the Environment task does a number of dynamic attachments of interrupt handlers during its elaboration they will all be deferred. It is perhaps not clear which should be the actual one attached once attachment occurs. One solution would be to ban Dynamic Attachments. c) At the last ARG meeting the view was taken that the AI should say what the Environment task should not do (ie how it can get blocked). However this list is quite long: - a select_statement (conditional entry call, or an ATC) - an entry_call_statement - an abort_statement - a call on a protected subprogram that performs an external call on a protected subprogram (or an external requeue) with the same target object as that of the outer protected subprogram - a call on a language-defined subprogram that is potentially blocking - a call on a subprogram whose body contains one of the above excluded operations. Hence have retained the original structure which list the acceptable blocking operations - but have included calling a protected entry which has a True barrier. !ACATS test !appendix [Editor's note: This originally was part of the Ravenscar proposal, see AI-249.] **************************************************************** From: Alan Burns Sent: Tuesday, January 7, 2003 4:13 AM Attached are my homework updates to these AIs [This is version AI-00265/02]. AI265 - partition elaboration; I do not quite agree with the minutes about allowing environment task to block and then raise program_error (which could not be caught). My recollection is that we were more concerned about saying what the env task could do or could not do. ****************************************************************