CVS difference for ai12s/ai12-0291-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0291-1.txt

--- ai12s/ai12-0291-1.txt	2018/10/12 01:32:27	1.1
+++ ai12s/ai12-0291-1.txt	2018/12/02 06:12:29	1.2
@@ -1,4 +1,4 @@
-!standard D.13(0)                                    18-10-11  AI12-0291-1/01
+!standard D.13(0)                                    18-11-26  AI12-0291-1/02
 !standard D.13(1/3)
 !standard D.13(4/3)
 !standard D.13(6/4)
@@ -7,6 +7,8 @@
 !standard D.13(11/4)
 !standard D.13(12/4)
 !class Amendment 18-10-11
+!status Amendment 1-2012 18-11-26
+!status ARG Approved 10-0-0  18-10-22
 !status work item 18-10-11
 !status received 18-08-09
 !priority Low
@@ -63,9 +65,9 @@
 Ada.Calendar package. Although relative delay statements are not 
 appropriate for expressing periodic behavior, there are cases in which a 
 relative delay has precisely the required semantics for embedded 
-applications. For example, an electro-mechanical relay may have a 
+applications. For example, an electromechanical relay may have a 
 requirement that it not be actuated more than N times per second in 
-order to prevent burn-out. A relative delay after each actuation 
+order to prevent burnout. A relative delay after each actuation 
 directly implements that requirement.
 
 The primary difference between the Ravenscar and Jorvik profiles is the 
@@ -167,6 +169,21 @@
                   No_Dependence =>
                        System.Multiprocessors.Dispatching_Domains);
 
+AARM Note: The Jorvik profile removes a number of restrictions from the 
+Ravenscar profile to allow additional applications to benefit from 
+predicability and low overhead. Specifically, the following restrictions
+are removed:
+    No_Implicit_Heap_Allocations
+    No_Relative_Delay
+    Max_Entry_Queue_Length => 1
+    Max_Protected_Entries => 1
+    No_Dependence => Ada.Calendar
+    No_Dependence => Ada.Synchronous_Barriers
+Jorvik also replaces restriction Simple_Barriers with Pure_Barriers (a weaker 
+requirement than Simple_Barriers).
+
+
+
                              Implementation Advice
 
 On a multiprocessor system, an implementation should support a fully
@@ -197,8 +214,147 @@
        also meets the requirements of the Yorvik profile.
 
 !discussion
+
+(See Proposal.)
+
+!corrigendum D.13(1/3)
+
+@drepl
+This subclause defines the Ravenscar profile.
+@dby
+This subclause defines the Ravenscar and Jorvik profiles.
+
+!corrigendum D.13(4/3)
+
+@drepl
+The @i<profile_>@fa<identifier> Ravenscar is a usage profile (see 13.12).
+For usage profile Ravenscar, there shall be no
+@i<profile_>@fa<pragma_argument_association>s.
+@dby
+The @i<profile_>@fa<identifier> Ravenscar and
+@i<profile_>@fa<identifier> Jorvik are usage profiles (see 13.12).
+For usage profiles Ravenscar and Jorvik, there shall be no
+@i<profile_>@fa<pragma_argument_association>s.
+
+!corrigendum D.13(6/4)
+
+@dinsa
+@xcode<@b<pragma> Task_Dispatching_Policy (FIFO_Within_Priorities);
+@b<pragma> Locking_Policy (Ceiling_Locking);
+@b<pragma> Detect_Blocking;
+@b<pragma> Restrictions (
+                No_Abort_Statements,
+                No_Dynamic_Attachment,
+                No_Dynamic_CPU_Assignment,
+                No_Dynamic_Priorities,
+                No_Implicit_Heap_Allocations,
+                No_Local_Protected_Objects,
+                No_Local_Timing_Events,
+                No_Protected_Type_Allocators,
+                No_Relative_Delay,
+                No_Requeue_Statements,
+                No_Select_Statements,
+                No_Specific_Termination_Handlers,
+                No_Task_Allocators,
+                No_Task_Hierarchy,
+                No_Task_Termination,
+                Simple_Barriers,
+                Max_Entry_Queue_Length =@> 1,
+                Max_Protected_Entries =@> 1,
+                Max_Task_Entries =@> 0,
+                No_Dependence =@> Ada.Asynchronous_Task_Control,
+                No_Dependence =@> Ada.Calendar,
+                No_Dependence =@> Ada.Execution_Time.Group_Budgets,
+                No_Dependence =@> Ada.Execution_Time.Timers,
+                No_Dependence =@> Ada.Synchronous_Barriers,
+                No_Dependence =@> Ada.Task_Attributes,
+                No_Dependence =@> System.Multiprocessors.Dispatching_Domains);>
+@dinss
+The usage profile Jorvik is equivalent to the following set of pragmas:
+
+@xcode<@b<pragma> Task_Dispatching_Policy (FIFO_Within_Priorities);
+@b<pragma> Locking_Policy (Ceiling_Locking);
+@b<pragma> Detect_Blocking;
+@b<pragma> Restrictions (
+                  No_Abort_Statements,
+                  No_Dynamic_Attachment,
+                  No_Dynamic_CPU_Assignment,
+                  No_Dynamic_Priorities,
+                  No_Local_Protected_Objects,
+                  No_Local_Timing_Events,
+                  No_Protected_Type_Allocators,
+                  No_Requeue_Statements,
+                  No_Select_Statements,
+                  No_Specific_Termination_Handlers,
+                  No_Task_Allocators,
+                  No_Task_Hierarchy,
+                  No_Task_Termination,
+                  Pure_Barriers,
+                  Max_Task_Entries =@> 0,
+                  No_Dependence =@> Ada.Asynchronous_Task_Control,
+                  No_Dependence =@> Ada.Execution_Time.Group_Budgets,
+                  No_Dependence =@> Ada.Execution_Time.Timers,
+                  No_Dependence =@> Ada.Task_Attributes,
+                  No_Dependence =@> System.Multiprocessors.Dispatching_Domains);>
+
+!corrigendum D.13(9/3)
+
+@drepl
+On a multiprocessor system, an implementation should support a fully 
+partitioned approach. Each processor should have separate and disjoint
+ready queues.
+@dby
+On a multiprocessor system, an implementation should support a fully
+partitioned approach if either of these profiles is specified. Each
+processor should have separate and disjoint ready queues.
+
+!corrigendum D.13(10/3)
+
+@drepl
+@xindent<@s9<NOTES@hr
+42 The effect of the Max_Entry_Queue_Length =@> 1 restriction applies
+only to protected entry queues due to the accompanying restriction of
+Max_Task_Entries =@> 0.>>
+@dby
+@xindent<@s9<NOTES@hr
+42 For the Ravenscar profile, the effect of the restriction
+Max_Entry_Queue_Length =@> 1 applies only to protected entry queues
+due to the accompanying restriction Max_Task_Entries =@> 0. The
+restriction Max_Entry_Queue_Length is not applied by the Jorvik
+profile.>>
+
+!corrigendum D.13(11/4)
+
+@drepl
+@xindent<@s9<43  When the Ravenscar profile is in effect (via the effect of the
+No_Dynamic_CPU_Assignment restriction), all of the tasks in the
+partition will execute on a single CPU unless the programmer explicitly
+uses aspect CPU to specify the CPU assignments for tasks. The use of
+multiple CPUs requires care, as many guarantees of single CPU scheduling
+no longer apply.>>
+@dby
+@xindent<@s9<43 When the Ravenscar or Jorvik profile is in effect (via the
+effect of the No_Dynamic_CPU_Assignment restriction), all of the
+tasks in the partition will execute on a single CPU unless the
+programmer explicitly uses aspect CPU to specify the CPU
+assignments for tasks. The use of multiple CPUs requires care,
+as many guarantees of single CPU scheduling no longer apply.>>
+
+!corrigendum D.13(12/4)
+
+@drepl
+@xindent<@s9<44  It is not recommended to specify the CPU of a task to be
+Not_A_Specific_CPU when the Ravenscar profile is in effect. How a partition
+executes strongly depends on the assignment of tasks to CPUs.>>
+@dby
+@xindent<@s9<44 It is not recommended to specify the CPU of a task to be
+Not_A_Specific_CPU when the Ravenscar or Jorvik profile is in
+effect. How a partition executes strongly depends on the
+assignment of tasks to CPUs.>>
+
+@xindent<@s9<45 Any unit that meets the requirements of the Ravenscar profile 
+also meets the requirements of the Yorvik profile.>>
 
-** TBD.
 
 !ASIS
 
@@ -207,8 +363,8 @@
 
 !ACATS test
 
-ACATS B- and C-Tests are needed to check that the new capabilities are
-supported.
+ACATS B- and C-Tests are needed to check that the new profile is
+supported and enforced.
 
 
 !appendix

Questions? Ask the ACAA Technical Agent