CVS difference for ais/ai-00249.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00249.txt

--- ais/ai-00249.txt	2000/12/06 21:46:44	1.1
+++ ais/ai-00249.txt	2001/05/11 03:46:21	1.2
@@ -1,11 +1,11 @@
-!standard D.2.2 (5)                                00-12-04  AI95-00249/01
+!standard D.2.2 (5)                                01-05-10  AI95-00249/02
 !standard D.7 (00)
 !class amendment 00-12-04
 !status work item 00-12-04
 !status received 00-12-04
 !priority High
 !difficulty Medium
-!subject Ravenscar Profile for High-Integrity Systems
+!subject Task Activation Policy for High-Integrity Systems
 
 !summary
 
@@ -20,33 +20,48 @@
 
 !proposal
 
-The comment proposes addition of pragma Ravenscar to Annex D of the RM as
-follows.
+This amendment proposes a pragma-based mechanism to allow the application to
+request use of the Ravenscar Profile. It proposes addition of a pragma
+to support the concept of a runtime profile. The amendment then proposes
+the runtime profile identifier "Ravenscar" to be defined in the standard
+and specifies its semantics.
+
+A runtime profile is an alternative mode of operation that is defined by
+the standard. It is selected by inclusion of the configuration pragma
+Runtime_Profile that applies to an active partition. The profile
+identifier "Ravenscar" selects the mode of operation to be the Ravenscar
+Profile.
 
-Pragma Ravenscar defines an alternative mode of operation that consists of the
-following amendments to the dynamic semantics of the standard. [Note: I say
-"alternative"  rather than "non-standard" as in section 1.5.  This is because
-its inclusion in the standard makes it not non-standard.]
+!wording
 
 Static Semantics
-	pragma Ravenscar;
+	pragma Runtime_Profile (profile_identifier [profile_argument_definition]);
 
-Pragma Ravenscar is a configuration pragma that applies to an active partition.
+The profile_identifier shall be either Ravenscar or an implementation-
+defined identifier.
 
 Dynamic Semantics
-1	Task Dispatching Policy
-The default Task_Dispatching_Policy for the active partition is
-FIFO_Within_Priorities.  An implementation may define alternative task
-dispatching policies.
 
-2	Locking Policy
-The default Locking_Policy for the active partition is Ceiling_Locking.  An
-implementation may define alternative locking policies.
+When profile_identifier Ravenscar is in effect, the following dynamic
+semantics apply:
 
-3	Restrictions pragmas
-3.1	Standard Pragmas
-The following pragma Restrictions identifiers defined in the standard apply to
-the alternative mode of operation defined by pragma Ravenscar:
+1.1. Task Dispatching Policy
+
+The default Task_Dispatching_Policy for the active partition shall be
+FIFO_Within_Priorities.
+
+1.2. Locking Policy
+
+The default Locking_Policy for the active partition shall be
+Ceiling_Locking.
+
+1.3. Restrictions Pragmas
+
+1.3.1. Standard Pragmas
+
+The following pragma Restrictions identifiers defined in the standard
+apply to the alternative mode of operation defined by the Ravenscar Profile:
+
 	Max_Asynchronous_Select_Nesting => 0
 	Max_Task_Entries => 0
 	Max_Protected_Entries => 1
@@ -54,121 +69,107 @@
 	No_Asynchronous_Control
 	No_Dynamic_Priorities
 	No_Implicit_Heap_Allocations
-	No_Task_Attributes
 	No_Task_Allocators
 	No_Task_Hierarchy
-The pragma No_Task_Hierarchy imposes the constraint that all tasks must depend
-immediately on the Environment task as a result of all task objects being
-created by library level declarations. [Note: It is not clear to me whether the
-existing RM wording fully implies this.  It is not sufficient to say that all
-tasks shall depend (directly or indirectly) on the Environment task since this
-presumably would include those declared inside library-level subprograms.  What
-we want to restrict is having to support "masters" and "waiting for dependent
-tasks"].
 
-3.2	Additional Pragmas
-The following new pragma Restrictions identifiers are defined as applying to the
-alternative mode of operation defined by pragma Ravenscar:
-[Aside: Alan Burns has a more complete write-up of these pragmas than is
-presented here.]
+1.3.2. New Pragmas
+
+The following new pragma Restrictions identifiers are defined as applying to
+the alternative mode of operation defined by the Ravenscar Profile:
+
 	Max_Entry_Queue_Depth = 1
-Max_Entry_Queue_Depth defines the maximum number of calls that are queued on a
-(protected) entry.  Violation of this restriction results in the raising of
-Program_Error exception at the point of the call. [Note: These semantics are
-intended to be consistent with those for blocking on a suspension object via
-Suspend_Until_True.]
+Max_Entry_Queue_Depth defines the maximum number of calls that are
+queued on a (protected) entry. Violation of this restriction results in the
+raising of Program_Error exception at the point of the call.
+
 	No_Calendar
 There are no semantic dependencies on package Ada.Calendar.
+
 	No_Dynamic_Attachment
 There is no call to any of the operations defined in package Ada.Interrupts
 (Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler,
-Detach_Handler, Reference) [Note: Static attachment via pragma Attach_Handler is
-supported.] {Note: At IRTAW-10, we called this No_Dynamic_Interrupt_Handlers,
-but that doesn't really convey the correct meaning of the restriction, hence my
-alternative suggestion.]
+Detach_Handler, Reference).
+
 	No_Local_Protected_Objects
 All protected objects are created via library-level declarations.
-[Note: This matches the additional semantics for No_Task_Hierarchy.  If these
-additional semantics were considered to be unacceptable, we could introduce
-No_Local_Task_Objects to go with this one.]
+
 	No_Protected_Type_Allocators
-There are no allocators for protected types or types containing protected type
-components. [Note: This is like No_Task_Allocators]
+There are no allocators for protected types or types containing
+protected type components.
+
 	No_Relative_Delay
 Delay_relative statements are not allowed.
-[Note: Unfortunately, No_Delay in H.4 is too strong since we want to allow
-delay_until Ada.Real_Time.Time, but not relative delay (non-deterministic) or
-Ada.Calendar (too coarse).]
+
 	No_Requeue
 Requeue statements are not allowed.
+
 	No_Select_Statements
 Select_statements are not allowed.
-[Note: This includes selective_accept (there are no task entries anyway), timed
-and conditional entry calls, and asynchronous_select (which is re-inforced by
-Max_Async_Select_Nesting = 0.]
-	No_Task_Termination
-No_Task_Termination defines task termination (including for the Environment
-task) to be a bounded error condition.  The possible effects are:
-	The task terminates as defined by the standard mode of operation.
-	Prior to termination as defined by the standard mode of operation, the task
-        calls an implementation-defined subprogram.  The mechanism for specifying the
-        subprogram to be called, and any restrictions on the operation of the
-        subprogram, are implementation-defined.
-[Note: This is defined so as to mitigate the hazard of "silent task death" in
-high integrity systems and to provide the opportunity for application-specific
-recovery action.]
-	Simple_Barrier_Variables
-The Boolean expression in an entry barrier shall be the value of a Boolean
-component of the enclosing protected object.
 
-4 Outstanding Issue -- Task_Activation
-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 to say, that no interrupts are delivered during this period of
-execution.  In addition, task activation shall be deferred until the completion
-of all elaboration code.
+	No_Task_Attributes
+There are no semantic dependencies on package Ada.Task_Attributes.
 
-A proposed approach to addressing this concern is to introduce an optional
-argument on the pragma Ravenscar such that the activation of library level tasks
-may be specified. This would have the effect of the modifing the syntax and
-semantics for pragma Ravenscar as follows:
+	Simple_Barrier_Variables
+The Boolean expression in an entry barrier shall be the value of a
+Boolean component of the enclosing protected object.
 
-Static Semantics
-	pragma Ravenscar[(Task_Activation => Deferred | Standard)];
+1.4. Bounded Error Detection
 
-Dynamic Semantics
+The bounded error that is the invocation of one of the following
+potentially blocking operations during a protected action shall be
+detected:
+-	a protected entry_call_statement
+-	a delay_until_statement
+-	a call to Ada.Synchronous_Task_Control.Suspend_Until_True
 
-4.1 Task_Activation => Deferred
-With the Deferred value for the Task_Activation argument, all task activation
-and all interrupt handler attachment for library-level tasks and interrupt
-handlers are deferred.  The deferred task activation and handler attachment
-occurs immediately after the "begin" of the Environment task.  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 call to
-Ada.Synchronous_Task_Control.Suspend_Until_True or to execute a protected entry
-call that is blocking during its declarative part.  Program_Error may be raised
-by the call, or the active partition may deadlock. [Note: In either case, the
-active partition is terminated.] It is a bounded error for any deferred task
-activation to fail.  The Environment task and all tasks whose activations fail
-are terminated.  A task whose activation succeeds may continue to execute, or
-may instead be immediately terminated, thereby completing execution of the
-partition. [Note: The preference is to terminate the partition immediately to
-mitigate the hazard posed by continuing execution with a subset of the tasks
-being active. However this would introduce code into the runtime to detect this
-corner case, so it is not mandated.]
-
-4.2	Task_Activation => Standard
-This value defines the execution of the declarative part of the Environment task
-to be as defined by the standard mode of operation with respect to task
-activation and interrupt handler attachment.
+Note
 
-!wording
+Detection of these bounded error cases results in Program_Error being
+raised (see 9.5.1(17)).
 
 !example
 
 !discussion
 
+a) Pragma Runtime_Profile is presented as an "alternative" mode of
+operation rather than a "non-standard" mode as in section 1.5 since its
+inclusion in the standard makes it not non-standard. Other profiles may
+be defined by an implementation, for example to define the Spark subset,
+or to define variations of the Ravenscar definition such as
+Ravenscar_Non_Preemptive.
+
+b) The pragma No_Task_Hierarchy must impose the constraint that all
+tasks depend immediately on the Environment task as a result of all task
+objects being created by library level declarations. It is not clear
+whether the existing RM wording fully implies this. It is not
+sufficient to say that all tasks shall depend (directly or indirectly)
+on the Environment task since this presumably would include those
+declared inside library-level subprograms. What we want to restrict is
+having to support "masters" and "waiting for dependent tasks". This
+also matches the semantics for pragma No_Local_Protected_Objects.
+
+c) The restrictions forcing the maximum length of an entry queue to be
+one and the maximum number of entries to be one are there for
+deterministic operation of entry queue servicing and to simplify the
+runtime implementation. The semantics are intended to be consistent with
+those for blocking on a suspension object via
+Suspend_Until_True.
+
+d) Static attachment of interrupt handlers via pragma Attach_Handler is
+supported.
+
+e) No_Protected_Type_Allocators matches existing restriction
+No_Task_Allocators.
+
+f) No_Delay in H.4 is too strong for the Ravenscar Profile since we want
+to allow delay_until Ada.Real_Time.Time, but not relative delay (non-
+deterministic) nor package Ada.Calendar (too coarse).
+
+g) No_Select_Statements excludes selective_accept (there are no task
+entries anyway), timed and conditional (protected) entry calls, and
+asynchronous_select (which is re-inforced by also requiring
+Max_Async_Select_Nesting = 0).
+
 !ACATS test
 
 !appendix
@@ -180,7 +181,7 @@
 !discussion
 
 This comment proposes the addition of support in the language standard for the
-de facto standard Ravenscar Profile.  This profile is included in the ISO
+de facto standard Ravenscar Profile. This profile is included in the ISO
 document "Guide for the use of the Ada programming language in high integrity
 systems".
 
@@ -189,7 +190,7 @@
 
 Pragma Ravenscar defines an alternative mode of operation that consists of the
 following amendments to the dynamic semantics of the standard. [Note: I say
-"alternative"  rather than "non-standard" as in section 1.5.  This is because
+"alternative"  rather than "non-standard" as in section 1.5. This is because
 its inclusion in the standard makes it not non-standard.]
 
 Static Semantics
@@ -200,11 +201,11 @@
 Dynamic Semantics
 1	Task Dispatching Policy
 The default Task_Dispatching_Policy for the active partition is
-FIFO_Within_Priorities.  An implementation may define alternative task
+FIFO_Within_Priorities. An implementation may define alternative task
 dispatching policies.
 
 2	Locking Policy
-The default Locking_Policy for the active partition is Ceiling_Locking.  An
+The default Locking_Policy for the active partition is Ceiling_Locking. An
 implementation may define alternative locking policies.
 
 3	Restrictions pragmas
@@ -224,9 +225,9 @@
 The pragma No_Task_Hierarchy imposes the constraint that all tasks must depend
 immediately on the Environment task as a result of all task objects being
 created by library level declarations. [Note: It is not clear to me whether the
-existing RM wording fully implies this.  It is not sufficient to say that all
+existing RM wording fully implies this. It is not sufficient to say that all
 tasks shall depend (directly or indirectly) on the Environment task since this
-presumably would include those declared inside library-level subprograms.  What
+presumably would include those declared inside library-level subprograms. What
 we want to restrict is having to support "masters" and "waiting for dependent
 tasks"].
 
@@ -237,7 +238,7 @@
 presented here.]
 	Max_Entry_Queue_Depth = 1
 Max_Entry_Queue_Depth defines the maximum number of calls that are queued on a
-(protected) entry.  Violation of this restriction results in the raising of
+(protected) entry. Violation of this restriction results in the raising of
 Program_Error exception at the point of the call. [Note: These semantics are
 intended to be consistent with those for blocking on a suspension object via
 Suspend_Until_True.]
@@ -252,7 +253,7 @@
 alternative suggestion.]
 	No_Local_Protected_Objects
 All protected objects are created via library-level declarations.
-[Note: This matches the additional semantics for No_Task_Hierarchy.  If these
+[Note: This matches the additional semantics for No_Task_Hierarchy. If these
 additional semantics were considered to be unacceptable, we could introduce
 No_Local_Task_Objects to go with this one.]
 	No_Protected_Type_Allocators
@@ -272,10 +273,10 @@
 Max_Async_Select_Nesting = 0.]
 	No_Task_Termination
 No_Task_Termination defines task termination (including for the Environment
-task) to be a bounded error condition.  The possible effects are:
+task) to be a bounded error condition. The possible effects are:
 	The task terminates as defined by the standard mode of operation.
 	Prior to termination as defined by the standard mode of operation, the task
-        calls an implementation-defined subprogram.  The mechanism for specifying the
+        calls an implementation-defined subprogram. The mechanism for specifying the
         subprogram to be called, and any restrictions on the operation of the
         subprogram, are implementation-defined.
 [Note: This is defined so as to mitigate the hazard of "silent task death" in
@@ -289,7 +290,7 @@
 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 to say, that no interrupts are delivered during this period of
-execution.  In addition, task activation shall be deferred until the completion
+execution. In addition, task activation shall be deferred until the completion
 of all elaboration code.
 
 A proposed approach to addressing this concern is to introduce an optional
@@ -305,17 +306,17 @@
 4.1 Task_Activation => Deferred
 With the Deferred value for the Task_Activation argument, all task activation
 and all interrupt handler attachment for library-level tasks and interrupt
-handlers are deferred.  The deferred task activation and handler attachment
-occurs immediately after the "begin" of the Environment task.  At this point,
+handlers are deferred. The deferred task activation and handler attachment
+occurs immediately after the "begin" of the Environment task. 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 call to
 Ada.Synchronous_Task_Control.Suspend_Until_True or to execute a protected entry
-call that is blocking during its declarative part.  Program_Error may be raised
+call that is blocking during its declarative part. Program_Error may be raised
 by the call, or the active partition may deadlock. [Note: In either case, the
 active partition is terminated.] It is a bounded error for any deferred task
-activation to fail.  The Environment task and all tasks whose activations fail
-are terminated.  A task whose activation succeeds may continue to execute, or
+activation to fail. The Environment task and all tasks whose activations fail
+are terminated. A task whose activation succeeds may continue to execute, or
 may instead be immediately terminated, thereby completing execution of the
 partition. [Note: The preference is to terminate the partition immediately to
 mitigate the hazard posed by continuing execution with a subset of the tasks

Questions? Ask the ACAA Technical Agent