CVS difference for ais/ai-00265.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00265.txt

--- ais/ai-00265.txt	2002/10/01 03:08:54	1.3
+++ ais/ai-00265.txt	2003/01/16 01:36:46	1.4
@@ -1,4 +1,4 @@
-!standard D.2.2 (5)                                02-09-05  AI95-00265/03
+!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
@@ -11,13 +11,14 @@
 
 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 prior to completion of the
-library-level elaboration code.
+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 termination semantics for Safety-Critical and High-Integrity applications.
+and interrupt handler execution semantics for Safety-Critical and
+High-Integrity applications.
 
 !proposal
 
@@ -47,6 +48,8 @@
 
 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> );
@@ -55,66 +58,76 @@
 Concurrent is the default.
 
 Legality Rules
-If the Policy_Identifier is Sequential then Pragma
-Restrictions (No_Task_Hierarchy) must have already been specified for
-the partition.
+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.
+The pragma is a configuration pragma. It applies to all compilation
+units in a partition.
 
 Dynamic Semantics
 
-Partition_Elaboration_Policy => Sequential
+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.
 
-With the Sequential value as the partition elaboration 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
-(see 10.2 (6)).  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 or
-task creation during its declarative part. Program_Error may be raised
-by the call, or the active partition may deadlock.
-
-In this mode of operation, if any deferred task activation fails then
-Tasking_Error exception is raised at the "begin" of the Environment Task.
-Since this is an implicit scope, it cannot declare any exception handlers, and
-hence 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 (see 10.2 (30)), thereby completing execution of the
-active partition.
+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 the Environment task executes a potentially blocking operation that is
-not a delay statement or task creation 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 (see 10.2 (30)).
-
-Partition_Elaboration_Policy => Concurrent
-
-With the Concurrent value as the partition elaboration 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.
+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) Do we need to say what happens if an interrupt does occur during
-elaboration?
+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
 
@@ -124,3 +137,18 @@
 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.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent