Version 1.11 of 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