Version 1.11 of ais/ai-00265.txt

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

!standard H.6 (00)          05-10-08 AI95-00265/09
!class amendment 01-05-10
!status Amendment 200Y 03-02-18
!status WG9 approved 03-06-20
!status ARG Approved 8-0-0 03-02-09
!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 activations are 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 the 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 ( policy_identifier );
The policy_identifier shall be either Sequential, Concurrent or an implementation-defined identifier.
Post-Compilation Rules A pragma Partition_Elaboration_Policy is a configuration pragma. It specifies the elaboration policy for a partition. At most one elaboration policy shall be specified for a partition.
If the Sequential policy is specified for a partition then pragma Restrictions (No_Task_Hierarchy) shall also be specified for the partition.
Dynamic Semantics
Notwithstanding what this International Standard says elsewhere, this pragma allows partition elaboration rules concerning task activation and interrupt attachment to be changed. If the policy_identifier is Concurrent, or if there is no pragma Partition_Elaboration_Policy defined for the partition, then the rules defined elsewhere in this Standard apply.
If the partition elaboration policy is Sequential, all task activations for library-level tasks and all interrupt handler attachments for library-level interrupt handlers are deferred. The deferred task activations and handler attachments occur 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 activations and handler attachments are complete.
If any deferred task activation fails, Tasking_Error is raised in the Environment task. The Environment task and all tasks whose activations fail are terminated. If a number of dynamic interrupt handler attachments for the same interrupt are deferred then the most recent call of Attach_Handler or Exchange_Handler determines which handler is attached.
Implementation Advice
If the partition elaboration policy is Sequential and the Environment task becomes permanently blocked during elaboration then the partition is deadlocked and it is recommended that the partition be immediately terminated.
Implementation Permission
If the partition elaboration policy is Sequential and any task activation fails then an implementation may immediately terminate the active partition to mitigate the hazard posed by continuing to execute with a subset of the tasks being active.
!example
!discussion
If, during the period while task activation is deferred, a function containing a task is called, we have trouble. The function is not allowed to return until the task terminates, but the task is not allowed to start! We have a deadlock situation. Therefore, we require the restriction No_Task_Hierarchy when the Partition_Elaboration_Policy is Sequential; this makes declaring such a function illegal.
!corrigendum H.06(01)
Insert new clause:
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 (policy_identifier);
The policy_identifier shall be either Sequential, Concurrent or an implementation-defined identifier.
Post-Compilation Rules
A pragma Partition_Elaboration_Policy is a configuration pragma. It specifies the elaboration policy for a partition. At most one elaboration policy shall be specified for a partition.
If the Sequential policy is specified for a partition then pragma Restrictions (No_Task_Hierarchy) shall also be specified for the partition.
Dynamic Semantics
Notwithstanding what this International Standard says elsewhere, this pragma allows partition elaboration rules concerning task activation and interrupt attachment to be changed. If the policy_identifier is Concurrent, or if there is no pragma Partition_Elaboration_Policy defined for the partition, then the rules defined elsewhere in this Standard apply.
If the partition elaboration policy is Sequential, all task activations for library-level tasks and all interrupt handler attachments for library-level interrupt handlers are deferred. The deferred task activations and handler attachments occur 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 activations and handler attachments are complete.
If any deferred task activation fails, Tasking_Error is raised in the Environment task. The Environment task and all tasks whose activations failed are terminated. If a number of dynamic interrupt handler attachments for the same interrupt are deferred then the most recent call of Attach_Handler or Exchange_Handler determines which handler is attached.
Implementation Advice
If the partition elaboration policy is Sequential and the Environment task becomes permanently blocked during elaboration then the partition is deadlocked and it is recommended that the partition be immediately terminated.
Implementation Permission
If the partition elaboration policy is Sequential and any task activation fails then an implementation may immediately terminate the active partition to mitigate the hazard posed by continuing to execute with a subset of the tasks being active.
!ACATS test
An ACATS C-Test and L-Test should be constructed for this pragma.
!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.

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

From: Randy Brukardt
Sent: Tuesday, February 18, 2003  7:08 PM

The wording of version /06 in several places says:
"If the @i<policy_>@fa<identifier> is Sequential,"
This is weird, because we're talking about the partition's policy, not
some instance of the pragma. It seems to imply that there is only one
instance of the pragma in some well-known place, but that is not
required by configuration pragmas. So, the syntax reference is inappropriate.

The wording would be better if it said something like:
"If the partition elaboration policy is Sequential,"

I've made this change in version /07.

It might be preferable if the term "partition elaboration policy" was
defined somewhere. I don't much like the idea of a nameless policy, people
are going to call it something. It seems likely that it will be referred to
as "partition elaboration policy" whether we officially name it that or not,
because that's the name of the pragma.

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


Questions? Ask the ACAA Technical Agent