CVS difference for ais/ai-00357.txt

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

--- ais/ai-00357.txt	2004/12/09 19:55:35	1.11
+++ ais/ai-00357.txt	2005/01/07 03:07:43	1.12
@@ -1,4 +1,4 @@
-!standard D.03 (00)                                  04-12-02  AI95-00357/07
+!standard D.02.6 (01)                                 04-12-30  AI95-00357/08
 !class amendment 03-09-27
 !status Amendment 200Y 04-12-02
 !status ARG Approved 10-0-0  04-11-20
@@ -173,6 +173,18 @@
 then the Ceiling_Locking policy (see D.3) shall also be specified for the
 partition.
 
+If the EDF_Across_Priorities policy appears in a
+Priority_Specific_Dispatching pragma (see D.2.2) in a partition, then the
+Ceiling_Locking policy (see D.3) shall also be specified for the
+partition.
+
+[Note: The above assumes AI-355 is included in the Amendment.]
+
+AARM Reason: The priority model of EDF assumes that ceiling locking is used;
+it wouldn't make sense otherwise. Other scheduling policies are not so tightly
+bound to the locking policy - they still can make sense for an alternative
+policy.
+
 Dynamic Semantics
 
 A Relative_Deadline pragma has no effect if it occurs in the declarative_part
@@ -332,8 +344,172 @@
 task preempted while executing in a PO must always stay
 at the front of its ready queue even if its deadline is later than
 the next task on the queue.
+
+!corrigendum D.2.6(1)
+
+@dinsc
+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 deadline
+and a dispatching policy that defines Earliest Deadline First (EDF)
+dispatching. A pragma is defined to assign an initial deadline to a task.
+
+@i<@s8<Static Semantics>>
+
+The @i<policy_>@fa<identifier> EDF_Across_Priorities is a task dispatching policy.
+
+The following language-defined library package exists:
+
+@xcode<@b<with> Ada.Real_Time;
+@b<with> Ada.Task_Identification;
+@b<package> Ada.Dispatching.EDF @b<is>
+  @b<subtype> Deadline @b<is> Ada.Real_Time.Time;
+  Default_Deadline : @b<constant> Deadline :=
+              Ada.Real_Time.Time_Last;
+  @b<procedure> Set_Deadline(D : @b<in> Deadline;
+              T : @b<in> Ada.Task_Identification.Task_ID :=
+              Ada.Task_Identification.Current_Task);
+  @b<procedure> Delay_Until_And_Set_Deadline(
+              Delay_Until_Time : @b<in> Ada.Real_Time.Time;
+              Deadline_Offset : @b<in> Ada.Real_Time.Time_Span);
+  @b<function> Get_Deadline(T : @b<in> Ada.Task_Identification.Task_ID :=
+              Ada.Task_Identification.Current_Task) @b<return> Deadline;
+@b<end> Ada.Dispatching.EDF;>
+
+@i<@s8<Syntax>>
+
+The form of a pragma Relative_Deadline is as follows:
+
+@xindent<@b<pragma> Relative_Deadline (@i<relative_deadline_>@fa<expression>);>
+
+@i<@s8<Name Resolution Rules>>
+
+The expected type for @i<relative_deadline_>@fa<expression> is
+Ada.Real_Time.Time_Span.
+
+@i<@s8<Legality Rules>>
+
+A Relative_Deadline pragma is allowed only immediately within a
+@fa<task_definition> or the @fa<declarative_part> of a @fa<subprogram_body>.
+At most one such pragma shall appear within a given construct.
+
+@i<@s8<Post-Compilation Rules>>
+
+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 the EDF_Across_Priorities policy appears in a
+Priority_Specific_Dispatching pragma (see D.2.2) in a partition, then the
+Ceiling_Locking policy (see D.3) shall also be specified for the
+partition.
+
+@i<@s8<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, 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 a task is the value of Default_Deadline.
+The environment task is also given an initial deadline by this rule.
+
+The procedure Set_Deadline changes the absolute deadline of the task to D.
+The function Get_Deadline returns the absolute deadline of the task.
+
+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.
+
+On a system with a single processor, the setting of a task's deadline
+to the new value occurs immediately at the first point that is outside the
+execution of an abort-deferred operation. 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 @i<Low>..@i<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 @i<T> to
+which policy EDF_Across_Priorities applies whenever:
+
+@xbullet<a change to the deadline of @i<T> occurs; or>
+
+@xbullet<a decrease to the deadline of any task on a ready queue for
+that processor occurs and the new deadline is earlier than
+that of the running task; or>
+
+@xbullet<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 @i<T> to which policy EDF_Across_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 @i<P>, if one exists, such that:
+@xbullet<a task is executing within a protected object with ceiling
+priority @i<P>; and>
+@xbullet<task @i<T> has an earlier deadline than any task executing within
+a protected object with ceiling priority @i<P>; and>
+@xbullet<the base priority of task @i<T> is greater than @i<P>.>
+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 queue.
+
+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 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.
+
+@i<@s8<Bounded (Run-Time) Errors>>
+
+If EDF_Across_Priorities is specified for priority range @i<Low>..@i<High>, it
+is a bounded error to declare a protected object with ceiling priority
+@i<Low> or to assign the value @i<Low> to attribute 'Priority. In either case
+either Program_Error is raised or the ceiling of the protected
+object is assigned the value @i<Low>+1.
+
+@i<@s8<Erroneous Execution>>
+
+If a value of Task_ID is passed as a parameter to any of the subprograms
+of this package and the corresponding task object no longer exists,
+the execution of the program is erroneous.
+
+@i<@s8<Documentation Requirements>>
+
+On a multiprocessor, the implementation shall document any conditions that
+cause the completion of the setting of a task's deadline to be delayed later
+than what is specified for a single procressor.
+
+@xindent<@s9<NOTES@hr
+16 If two adjacent priority ranges, @i<A>..@i<B> and @i<B>+1..@i<C> are
+specified to have policy
+EDF_Across_Priorities then this is not equivalent to this policy being
+specified for the single range, @i<A>..@i<C>.>>
+
+@xindent<@s9<17 The above rules implement the preemption-level protocol (also
+called Stack Resource Policy protocol) for resource sharing under EDF
+dispatching. The preemption-level for a task is denoted by its base priority.
+The definition of a ceiling preemption-level for a protected object follows the
+existing rules for ceiling locking.>>
+
 
---!corrigendum
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent