CVS difference for ais/ai-00357.txt

Differences between 1.9 and version 1.10
Log of other versions for file ais/ai-00357.txt

--- ais/ai-00357.txt	2004/09/14 01:25:57	1.9
+++ ais/ai-00357.txt	2004/10/26 23:52:26	1.10
@@ -1,4 +1,4 @@
-!standard D.03 (00)                                  04-09-06  AI95-00357/05
+!standard D.03 (00)                                  04-10-10  AI95-00357/06
 !class amendment 03-09-27
 !status work item 03-09-27
 !status received 03-09-27
@@ -26,7 +26,7 @@
 For many scheduling schemes, including for example EDF, the most effective
 locking policy for protected objects is one known as the Stack Resource
 Policy (or preemption level locking). This was defined
-by Baker in 1991 [1] and has the advantage that is does not enforce the
+by Baker in 1991 [1] and has the advantage that it does not enforce the
 same policy on task dispatching and PO locking; but it does lead to
 effective implementation of POs. Moreover when priority dispatching
 is used the SRP policy is the same as ceiling locking.
@@ -55,7 +55,7 @@
 In this proposal
 
 a) deadlines are represented by a new task 'attribute'
-b) preemption levels for tasks are represented by base priority
+b) preemption levels for tasks are represented by base priorities
 c) preemption levels for POs are represented by ceiling priorities
 
 The usual behaviour of priorities, when tasks execute within a PO,
@@ -107,24 +107,28 @@
 Rule 5
 Priority ceiling level Priority'first is not allowed.
 
+
 !wording
+
+D.2.6 Earliest Deadline First Dispatching
 
-D.2.5 Earliest Deadline First Dispatching
+The deadline of a task is an indication of the urgency of the task; it
+represents a point on an ideal physical time-line. Unless otherwise specified,
+whenever tasks compete for processors or other implementation-defined
+resources, the resources are allocated to the task with the earliest deadline.
 
-This clause defines a package for representing a task's absolute deadline
+This clause defines a package for representing a task's deadline
 and a dispatching policy that defines Earliest Deadline First (EDF)
-dispatching. A pragma is defined to allow a task to be assigned
-a relative deadline to control its activation.
+dispatching. A pragma is defined to assign an initial deadline to a task.
 
-The absolute deadline of a task is an indication of the urgency of the task.
-Unless otherwise specified, whenever tasks compete for processors or other
-implementation-defined resources, the resources are allocated to the task with
-the earliest absolute deadline.
+AARM Note:
+This pragma is the only way of assigning an initial deadline to a task so
+that its activation can be controlled by EDF scheduling. This is similar to
+the way pragma Priority is used to give an initial priority to a task.
 
 Static Semantics
 
-The policy_identifier EDF_Across_Priority designates a
-task dispatching policy.
+The policy_identifier EDF_Across_Priorities is a task dispatching policy.
 
 The following language-defined library package exists:
 
@@ -144,15 +148,6 @@
               Ada.Task_Identification.Current_Task) return Deadline;
 end Ada.Dispatching.EDF_Dispatching;
 
-If the EDF_Across_Priorities policy is specified for a partition,
-then the Ceiling_Locking policy (see D.3) shall also be specified for the
-partition.
-
-If task dispatching policy EDF_Across_Priorities is in effect for any
-range of priorities within a partition then all tasks in that partition
-have deadline Default_Deadline unless modified by pragma Relative_Deadline
-or calls of Set_Deadline.
-
 Syntax
 
 The form of a pragma Relative_Deadline is as follows:
@@ -167,73 +162,95 @@
 Legality Rules
 
 A Relative_Deadline pragma is allowed only immediately within a
-task_definition. At most one such pragma shall appear within a given
-task_definition.
+task_definition or the declarative_part of a subprogram_body.
+At most one such pragma shall appear within a given construct.
+
+Post-Compilation Rules
 
-When EDF_Across_Priorities is in effect for priority range Low..High,
-no protected object shall have ceiling priority Low.
-NOT SURE THIS SHOULD BE A LEGALITY RULE AS CEILINGS CAN NOW CHANGE
+If the EDF_Across_Priorities policy is specified for a partition,
+then the Ceiling_Locking policy (see D.3) shall also be specified for the
+partition.
 
 Dynamic Semantics
 
+A Relative_Deadline pragma has no effect if it occurs in the declarative_part
+of the subprogram_body of a subprogram other than the main subprogram.
+
 The initial absolute deadline of a task containing pragma Relative_Deadline
-is the value of Ada.Real_Time.Clock + relative_deadline_expression.
-The call of Ada.Real_Time.Clock being made between task creation and the
+is the value of Ada.Real_Time.Clock + relative_deadline_expression, where
+the call of Ada.Real_Time.Clock is made between task creation and the
 start of its activation. If there is no Relative_Deadline pragma then the
-initial absolute deadline of the task is the value of Default_Deadline.
-
-A call of Set_Deadline changes the absolute deadline of the task to D.
-A call of Get_Deadline returns the absolute deadline of the task.
+initial absolute deadline of a task is the value of Default_Deadline.
+The environment task is also given an initial deadline by this rule.
 
-Setting the task's absolute deadline to the new value takes place as soon as
-is practical but not while the task is performing a protected action.
+The procedure Set_Deadline changes the absolute deadline of the task to D.
+The function Get_Deadline returns the absolute deadline of the task.
 
-A call of Delay_Until_And_Set_Deadline delays the calling task until time
+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 + TS.
 
-When EDF_Across_Priorities is in effect for priority range Low..High,
-modifications to the ready queues occur only as follows:
+Setting the deadline of a task to a new value takes place as soon as
+is practical but not while the task is performing a protected action.
+This setting occurs no later than the next abort completion point
+of the task (see 9.8). If the task is currently on a ready queue it
+is removed and re-entered on to the ready queue determined by the
+rules defined below.
+
+When EDF_Across_Priorities is specified for priority range Low..High
+all ready queues in this range are ordered by deadline.
+The task at the head of a queue is the one with the earliest
+deadline.
+
+A task dispatching point occurs for the currently running task T to
+which policy EDF_Within_Priorities applies whenever:
+
+  o a change to the deadline of T takes effect; or
+
+  o a decrease to the deadline of any task on a ready queue for
+    that processor takes effect and the new deadline is earlier than
+    that of the running task; or
+
+  o there is a non-empty ready queue for that processor
+    with a higher priority than the priority of the running task.
+
+The currently running task is said to be preempted and is returned to
+the ready queue for its active priority.
+
+Whenever a task T to which policy EDF_Within_Priorities applies is
+added to a ready queue, other than when it is preempted, it is placed on
+the ready queue with the highest priority R, if one exists, such that:
+   o  a task is executing within a protected object with ceiling
+       priority R; and
+   o  task T has an earlier deadline than any task executing within
+      a protected object with ceiling priority R; and
+   o  the base priority of task T is greater than R.
+If no such ready queue exists the task is added to the ready
+queue for the lowest priority in the range specified as
+EDF_Across_Priorities.
+
+When the setting of the base priority of a task takes effect and the
+new priority is in the range specified as EDF_Across_Priorities,
+the task is added to the ready queues.
 
-o All ready queues in the range Low..High are ordered by deadline.
-  The task at the head of a queue is the one with the earliest
-  absolute deadline.
-
-o When a task becomes unblocked it is placed on the highest
-  priority ready queue with priority R such that:
-     i)   a task is executing within a protected object with ceiling
-          priority R,
-     ii)  the unblocked task has an earlier deadline than any task
-          executing within a protected object with ceiling
-          priority R, and
-     iii) the base priority of the unblocked task is greater than R.
-  If no such protected object exists the task is added to the ready
-  queue for Low.
-
-o When the setting of the base priority (to a value in the range
-  Low..High) of a running task takes effect, the task is added to
-  the ready queue determined by the preceding rule.
-
-o When a task is chosen for execution it runs with the active priority
-  determined by the ready queue from which the task was taken. If
-  preempted it returns to the ready queue for its active priority.
-  If it inherits a higher active priority it will return to its
-  original active priority when it no longer inherits the higher
-  level.
-
-o A task dispatching point occurs for the currently running task
-  whenever a task has its deadline changed.
-
-When task dispatching policy EDF_Across_Priorities is in effect a
-task dispatching point occurs for the currently running task of a
-processor whenever there is a non-empty ready queue for that processor
-with a higher priority than the priority of the running task.
+When a task is chosen for execution it runs with the active priority
+of the ready queue from which the task was taken.
+If it inherits a higher active priority it will return to its
+original active priority when it no longer inherits the higher
+level.
 
-For all the operations and types defined in this package, Tasking_Error
+For all the operations defined in this package, Tasking_Error
 is raised if the task identified by T has terminated. Program_Error
 is raised if the value of T is Null_Task_ID.
 
+Bounded (Run-Time) Error
 
+If EDF_Across_Priorities is specified for priority range Low..High, it
+is a bounded error to declare a protected object with ceiling priority
+Low or to assign the value Low to attribute 'Priority. In either case
+either Program_Error is raised or the ceiling of the protected
+object is assigned the value Low+1.
+
 Erroneous Execution
 
 If a value of Task_ID is passed as a parameter to any of the subprograms
@@ -242,10 +259,9 @@
 
 Notes
 
-If two adjacent priority ranges, A..B and B+1..C are allocated policy
-EDF_Across_Priorities then this is not equivalent to a single range, A..C.
-For policies FIFO_Within_Priorities and Round_Robin_Within_Priorities they
-are equivalent.
+If two adjacent priority ranges, A..B and B+1..C are specified to have policy
+EDF_Across_Priorities then this is not equivalent to this policy being
+specified for the single range, A..C.
 
 The above rules implement the preemption-level protocol (also called
 Stack Resource Policy protocol) for resource sharing under EDF
@@ -253,9 +269,11 @@
 priority. The definition of a ceiling preemption-level for a protected
 object follows the existing rules for ceiling locking.
 
+AARM Note:
 An implementation may support additional dispatching policies by replacing
 absolute deadline with an alternative measure of urgency.
 
+
 !discussion
 
 The addition of procedure Delay_and_Set_Relative_Deadline reflects
@@ -281,20 +299,21 @@
 S, it has a shorter deadline and hence will execute first.
 
 If some other task has locked the PO then S must have preempted it
-and hence will again be on the ready q for this level. T added to
-same q and will preempt.
+and hence will again be on the ready queue for this level. T added to
+same queue and will preempt. [What the heck does this last sentence mean? Note
+that I fixed many more instances of 'q' to be 'queue'. - ED]
 
 If there are a number of locked POs then T needs to be placed on the
-correct ready q. On all ready queues, apart from that at Priority'first,
-the tail of the q is the task that has the lock on the PO whose
-ceiling pri is that of the ready q. Rule 2 then gets the right q:
-the q is appropriate as T has the correct attributes (shorter
+correct ready queue. On all ready queues, apart from that at Priority'first,
+the tail of the queue is the task that has the lock on the PO whose
+ceiling pri is that of the ready queue. Rule 2 then gets the right queue:
+the queue is appropriate as T has the correct attributes (shorter
 deadline than the task holding the lock, and higher preemption
-level). Moreover no higher pri q is appropriate as one of the
+level). Moreover no higher priority queue is appropriate as one of the
 conditions will be false.
 
-Note that in order to be placed on a ready q, T must have a strictly
-higher preemption level (base priority) than the task on that q that
+Note that in order to be placed on a ready queue, T must have a strictly
+higher preemption level (base priority) than the task on that queue that
 is holding the lock. Hence mutual exclusion is not broken by
 the preemption rules.
 
@@ -305,7 +324,7 @@
 rule. But it did require that tasks be placed at one above
 the level in the above model, and required the rule that a
 task preempted while executing in a PO must always stay
-at the front of its ready q even if its deadline is later than
+at the front of its ready queue even if its deadline is later than
 the next task on the queue.
 
 

Questions? Ask the ACAA Technical Agent