Version 1.4 of ais/ai-00265.txt
!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
!subject Partition Elaboration Policy for High-Integrity Systems
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.
There are determinism and hazard mitigation issues relating to task activation
and interrupt handler execution semantics for Safety-Critical and
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
New section H.6:
H.6 Pragma Partition_Elaboration_Policy
This clause defines a pragma for user control over elaboration policy.
The form of a pragma Partition_Elaboration_Policy is as follows:
pragma Partition_Elaboration_Policy ( <Policy_Identifier> );
The Policy_Identifier shall be either Sequential or Concurrent;
Concurrent is the default.
If the Sequential policy is specified for a
partition then pragma Restrictions (No_Task_Hierarchy) shall
also be specified for the partition.
The pragma is a configuration pragma. It applies to all compilation
units in a partition.
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.
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.
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.
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
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
Hence have retained the original structure which list the acceptable
blocking operations - but have included calling a protected entry which
has a True barrier.
[Editor's note: This originally was part of the Ravenscar proposal,
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.
Questions? Ask the ACAA Technical Agent