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

Differences between 1.5 and version 1.6
Log of other versions for file ai12s/ai12-0230-1.txt

--- ai12s/ai12-0230-1.txt	2018/10/19 05:59:55	1.5
+++ ai12s/ai12-0230-1.txt	2018/11/28 01:39:12	1.6
@@ -1,4 +1,4 @@
-!standard D.2.6(9/2)                                  18-10-17  AI12-0230-1/03
+!standard D.2.6(9/2)                                  18-10-22  AI12-0230-1/04
 !standard D.2.6(9.1/3)
 !standard D.2.6(29/2)
 !standard D.3(13)
@@ -6,6 +6,8 @@
 !standard D.5.2(3/2)
 !standard D.5.2(4/2)
 !class Amendment 17-06-05
+!status Amendment 1-2012 18-11-27
+!status ARG Approved 7-0-3  18-10-22
 !status work item 17-06-05
 !status received 17-05-02
 !priority Low
@@ -33,7 +35,7 @@
 deprecated.
 
 For Ravenscar-like tasks with no self-suspension there is a static relationship
-between a task's relative and absolute deadlines. For such task it would be
+between a task's relative and absolute deadlines. For such a task it would be
 advantageous if the run-time automatically updates the absolute deadline of
 the task when it becomes ready for execution (i.e. runnable).
 
@@ -60,9 +62,9 @@
 The action of the protocol on a single processor with tasks that do not
 self-suspend results in a single block per task, deadlock free execution and the
 protocol works for nested calls on protected objects (PO). While a task accesses
-a PO its deadline is reduced so that no newly released tasks can preempt it and
+a PO, its deadline is reduced so that no newly released tasks can preempt it and
 then access the PO. See [1,2,3] for details and proof of the key properties.
-This is equivalent to the use of a priority ceiling; again the only tasks that
+This is equivalent to the use of a priority ceiling; again, the only tasks that
 can preempt a task executing within a protected object are tasks that are
 guaranteed not to use that object (unless there is a program error, which can be
 caught at run-time).
@@ -77,12 +79,12 @@
 at the last (2018) IRTAW an alternative check was proposed, this is included
 in the discussion below).
 
-There two styles of programming that can be applied to EDF-based
+There are two styles of programming that can be applied to EDF-based
 scheduled systems. In one (which fits with hard real-time systems and
 hence Ravenscar) each task has a relative deadline and every time it is made
 runnable the run-time system can assign a new absolute deadline.
 The relative deadline aspect will usually be constant, but to
-program mode changes an application should be allowed to change it.
+program mode changes, an application should be allowed to change it.
 With the second programming style (which fits more with soft real-time)
 tasks directly update their own absolute deadlines; there is less use
 of the notion of relative deadline although the minimum relative deadline
@@ -120,7 +122,7 @@
 5) Rules for EDF scheduling need simplifying to remove the 'across priorities'
    feature of the current definition.
 
-6) A configuration pragma (Generate_Deadlines?) is defined that requires each
+6) A configuration pragma (Generate_Deadlines) is defined that requires each
    task's absolute deadline to be computed by the run-time each time the task
    becomes runnable.
 
@@ -160,7 +162,7 @@
       Delay_Until_Time : in Ada.Real_Time.Time;
       Deadline_Offset : in Ada.Real_Time.Time_Span :=
       Get_Relative_Deadline);
-  function Get_Last_Release_Time(T :
+  function Get_Last_Release_Time (T :
       Ada.Task_Identification.Task_Id :=
       Ada.Task_Identification.Current_Task)
       return Ada.Real_Time;
@@ -222,12 +224,12 @@
 o Whenever a task is executing outside a protected action, its active deadline
   is equal to its base deadline.
 
-o When a task executes a protected action its active deadline will be reduced to
-  (if it is currently greater than) 'now' plus the deadline floor of the
+o When a task executes a protected action, its active deadline will be reduced
+  to (if it is currently greater than) 'now' plus the deadline floor of the
   corresponding protected object; 'now' is obtained via use of the real-time
   clock (i.e. the clock that supports the Ada.Real_Time library package).
 
-o When a task completes a protected action its active deadline returns to the
+o When a task completes a protected action, its active deadline returns to the
   value it had on entry.
 
 o When a task calls a protected operation, a check is made that (absolute
@@ -287,38 +289,39 @@
   Default_Deadline : constant Deadline :=
       Ada.Real_Time.Time_Last;
   Default_Relative_Deadline : constant
-      Relative_Deadline :=
-      Real_Time.Time_Span_Last;
-  procedure Set_Deadline (D : in Deadline;
+      Relative_Deadline := Real_Time.Time_Span_Last;
+  procedure Set_Deadline
+     (D : in Deadline;
       T : in Ada.Task_Identification.Task_Id :=
       Ada.Task_Identification.Current_Task);
-  function Get_Deadline (T : Ada.Task_Identification.Task_Id :=
+  function Get_Deadline
+     (T : Ada.Task_Identification.Task_Id :=
       Ada.Task_Identification.Current_Task) return Deadline;
   procedure Set_Relative_Deadline
-      (D : in Relative_Deadline;
+     (D : in Relative_Deadline;
       T : in Ada.Task_Identification.Task_Id :=
       Ada.Task_Identification.Current_Task);
-  function Get_Relative_Deadline (T :
-      Ada.Task_Identification.Task_Id :=
+  function Get_Relative_Deadline
+     (T : Ada.Task_Identification.Task_Id :=
       Ada.Task_Identification.Current_Task)
       return Relative_Deadline;
-  procedure Delay_Until_And_Set_Deadline (
-      Delay_Until_Time : in Ada.Real_Time.Time;
+  procedure Delay_Until_And_Set_Deadline
+     (Delay_Until_Time : in Ada.Real_Time.Time;
       Deadline_Offset : in Ada.Real_Time.Time_Span :=
       Get_Relative_Deadline);
-  function Get_Last_Release_Time (T :
-      Ada.Task_Identification.Task_Id :=
+  function Get_Last_Release_Time
+     (T : Ada.Task_Identification.Task_Id :=
       Ada.Task_Identification.Current_Task)
       return Ada.Real_Time.Time;
 end Ada.Dispatching.EDF;
 
 For a subprogram, a task type (including the anonymous type of a
 single_task_declaration), or a protected type (including the anonymous
-type of a single_protected_declaration) the following language-defined
+type of a single_protected_declaration), the following language-defined
 representation aspect may be specified:
 
 Relative_Deadline
-  The Relative_Deadline aspect is an expression, of type
+  The Relative_Deadline aspect is an expression of type
   Ada.Real_Time.Time_Span.
 
 The form of pragma Generate_Deadlines is as follows:
@@ -352,16 +355,15 @@
 Real_Time.Clock at the time the task is added to a ready queue plus the
 value returned by Get_Relative_Deadline.
 
-The initial absolute deadline for a task with a specified
-Relative_Deadline is the result of evaluating the expression
-Real_Time.Clock + the expressions specified as the Relative_Deadline
-aspect, where this entire expression, including the call of
-Real_Time.Clock, is evaluated between task creation and the start of its
-activation. If the aspect Relative_Deadline is not specified, then the
-initial absolute deadline of a task is the value of Default_Deadline
-(Ada.Real_Time.Time_Last). The environment task is also given an initial
-deadline by this rule, using the value of the Relative_Deadline aspect
-of the main subprogram (if any).
+The initial absolute deadline for a task with a specified Relative_Deadline is
+the result of adding the value returned by a call of Real_Time.Clock to the
+value of the expression specified as the Relative_Deadline aspect, where this
+entire computation, including the call of Real_Time.Clock, is performed between
+task creation and the start of its activation. If the aspect Relative_Deadline
+is not specified, then the initial absolute deadline of a task is the value of
+Default_Deadline (Ada.Real_Time.Time_Last). The environment task is also given
+an initial deadline by this rule, using the value of the Relative_Deadline
+aspect of the main subprogram (if any).
 
 The effect of specifying a Relative_Deadline aspect for a protected type or
 single_protected_declaration is discussed in D.3.
@@ -378,12 +380,12 @@
 deadline of the task.
 
 The function Get_Last_Release_Time returns the time, as provided by
-Real_Time.Clock, when the task was last made runnable (i.e. added to a
+Real_Time.Clock, when the task was last made runnable (that is, was added to a
 ready queue).
 
 The procedure Delay_Until_And_Set_Deadline delays the calling task until
 time Delay_Until_Time. When the task becomes runnable again it will have
-deadline Delay_Until_Time + Deadline_Offset.
+deadline [code font: Delay_Until_Time + Deadline_Offset].
 
 On a system with a single processor, the setting of the deadline of a task
 to the new value occurs immediately at the first point that is outside the
@@ -561,12 +563,12 @@
 
 !ASIS
 
-[Not sure. It seems like some new capabilities might be needed for operators,
-but I didn't check - Editor.]
+[Not sure. It seems like some new capabilities might be needed to support the
+new aspects and attributes, but I didn't check - Editor.]
 
 !ACATS test
 
-An ACATS C-Test is needed to check that the new capabilities are supported.
+ACATS C-Tests are needed to check that the new capabilities are supported.
 
 
 !appendix

Questions? Ask the ACAA Technical Agent