CVS difference for ais/ai-00355.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00355.txt

--- ais/ai-00355.txt	2003/11/25 02:23:53	1.3
+++ ais/ai-00355.txt	2004/02/21 03:05:52	1.4
@@ -1,4 +1,4 @@
-!standard D.03 (00)                                  03-11-24  AI95-00355/02
+!standard D.03 (00)                                  04-02-19  AI95-00355/03
 !class amendment 03-09-27
 !status work item 03-09-27
 !status received 03-09-27
@@ -37,196 +37,258 @@
 
 !proposal
 
-(See wording.)
+Section D.2 (Priority Scheduling) currently has 4 subsections:
 
-!wording
-
-Add two new sections:
-
-D.2.5 The Priority Specific Dispatching Policy
+2.1 The Dispatching Model
+2.2 Pragma Task_Dispatching_Policy
+2.3 Preemptive Dispatching
+2.4 Non-Preemptive Dispatching
+
+Two new specific policies as proposed (Round Robin in this AI and EDF
+in AI 357). In addition a means of specify mixed scheduling is proposed
+in this AI. The ARG expressed the wish for the specific policies
+to be defined in their own right and then the mixed scheme defined.
+Hence the proposed new subsections are;
+
+2.5 Round Robin Dispatching
+2.6 Earliest Deadline First Dispatching
+2.7 Priority Specific Dispatching
 
-A priority specific dispatching policy is defined via policy_identifier
-Priority_Specific. When Priority_Specific dispatching is
-in effect, tasks within the range of priorities specified are dispatched
-according to a single dispatching policy.
-
-Syntax
+This AI deals with 2.5 and 2.7 (but will assume EDF is also to
+be supported).
 
-The form of a pragma Priority_Policy is as follows:
+In addition a new (empty) package is added to D.2.2 for parameters
+to dispatching policies. Child packages are defined in 2.5, 2.6 and 2.7.
 
-pragma Priority_Policy (priority_policy_identifier,
-                        first_priority, last_priority
-                        {,policy_parameter});
+!wording
 
+Add before Dynamic Semantics to D.2.1 (as updated by AI-321).
 
-Name Resolution Rules
+Static Semantics
 
-The expected type for first_priority and last_priority is integer.
-The expected type for any policy_parameter is either integer or
-universal real.
+The following language-defined library package exists:
 
-Legality Rules
+package Ada.Dispatching is
+  pragma Pure(Ada);
+end Ada.Dispatching;
 
-Priority_Specific can be specified as the policy_identifier
-of pragma Task_Dispatching_Policy (see D.2.2).
+Dispatching serves as the parent of other language-defined library
+units concerned with dispatching; its declaration is empty (except for
+the pragma Pure).
 
-The priority_policy_identifier shall be FIFO_Within_Priorities,
-Round_Robin_Within_Priorities, EDF_Within_Priorities or an
-implementation-defined identifier.
+Add a new section:
 
-Both first_priority and last_priority are static expressions;
-last_priority has a value greater or equal to first_priority.
-Any policy_parameter is a static expression.
-
-For priority_policy_identifier FIFO_Within_Priorities there shall
-be no policy_parameter, and first_priority must equal last_priority.
-
-For priority_policy_identifier Round_Robin_Within_Priorities there
-shall be at most one single policy_parameter, and first_priority
-must equal last_priority.
+D.2.5 Round Robin Dispatching
 
-For priority_policy_identifier EDF_Within_Priorities there shall
-be no policy_parameter.
+This clause defines the policy_identifier, Round_Robin_Within_Priorities,
+and package Round_Robin_Dispatching.
 
 Post-Compilation Rules
-
-A Priority_Policy pragma is a configuration pragma.
 
-If the Priority_Specific policy is specified for a partition, then
-the Ceiling_Locking policy (see D.3) shall also be specified for the
+If the Round_Robin_Within_Priorities policy is specified for a partition,
+then the Ceiling_Locking policy (see D.3) shall also be specified for the
 partition.
 
 Static Semantics
 
-If the same priority is specified in more than one Priority_Policy
-pragma, the partition is rejected.
-
-If Task_Dispatching_Policy is not Priority_Specific for the
-partition in which a pragma Priority_Policy appears, then the
-partition is rejected.
-
-If the values of first_priority and last_priority are not in
-the range of System.Any_Priority the partition is rejected.
-
-At all priority levels, the default Priority_Policy is
-FIFO_Within_Priorities.
-
-
-Dynamic Semantics
-
-When task dispatching policy is Priority_Specific 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.
-
-The rules for tasks on priority levels with FIFO_Within_Priorities are
-as defined for that dispatching policy (D.2.3).
-
-
-D.2.6 The Round Robin Dispatching Policy
-
-This clause defines the priority_policy_identifier,
-Round_Robin_Within_Priorities, and package Round_Robin_Dispatching.
-
-Static Semantics
-
 The following language-defined library package exist:
 
 with System;
-package Ada.Real_Time.Round_Robin_Dispatching is
-  Default_Quantum : constant Time_Span := <implementation-defined>;
-  function Round_Robin(Pri : System.Priority) return Boolean;
+with Ada.Real_Time;
+package Ada.Dispatching.Round_Robin_Dispatching is
+  Default_Quantum : constant Ada.Real_Time.Time_Span :=
+             <implementation-defined>;
+  procedure Set_Quantum(Pri : System.Priority;
+             Quantum : Ada.Real_Time.Time_Span);
+  procedure Set_Quantum(Low,High : System.Priority;
+             Quantum : Ada.Real_Time.Time_Span);
   function Actual_Quantum
-           (Pri : System.Priority) return Time_Span;
-  Priority_Error : exception;
-end Ada.Real_Time.Round_Robin_Dispatching;
-
-For priority_policy_identifier Round_Robin_Within_Priorities the
-single policy_parameter (if present) gives the size of the required
-quantum in milliseconds. If no parameter is given, Default_Quantum
-is used.
+           (Pri : System.Priority) return Ada.Real_Time.Time_Span;
+end Ada.Dispatching.Round_Robin_Dispatching;
+
+When task dispatching policy Round_Robin_Within_Priorities is in effect,
+tasks with priority in the range of System.Interrupt_Priority are
+dispatched according to policy FIFO_Within_Priorities.
 
 Dynamic Semantics
 
-The Round_Robin function returns True if the specified priority level has
-been allocated Round_Robin_Within_Priorities; otherwise it returns False.
+A call of either Set_Quantum procedure sets the required quantum value
+for the priority level Pri in the first procedure, and the levels in
+the range Low..High for the second procedure. If no quantum is set for
+a priority level, Default_Quantum is used.
 
 The function Actual_Quantum returns the actual quantum used
-by the implementation for the priority level given; the exception
-Priority_Error is raised if this is not a round robin dispatching priority.
+by the implementation for the priority level Pri.
 
-For Round_Robin_Within_Priorities, the same dispatching rules
+For Round_Robin_Within_Priorities, the dispatching rules
 for FIFO_Within_Priorities apply with the following additional rules.
-A task is referred to as a RR task if its base priority is one designated
-as Round_Robin_Within_Priorities.
 
-  When a RR task is added to the tail of the ready queue for its base
+o When task is added to the tail of the ready queue for its base
   priority, it has an execution time budget set equal to the quantum for
   that priority level. This will also occur when a blocked task becomes
   executable again.
 
-  When a RR task is preempted (by a higher priority task), it is added to the
-  head of the ready queue for its priority level. It retains its remaining budget.
+o When a task is preempted (by a higher priority task) and is added to the
+  head of the ready queue for its priority level, it retains its remaining
+  budget.
 
-  When a RR task is executing, its budget is decreased by the amount of
-  execution time it uses. The accuracy of this accounting follows the
+o When a task is executing, its budget is decreased by the amount of
+  execution time it uses. The accuracy of this accounting follows
   that for execution time clocks (D.14).
 
-  A task that has its base priority changed, via the use of Set_Priority, may
-  move to, or from, a round robin priority level. If it is moved to a round
-  robin level then it is placed at the tail of the ready queue and given a
-  full quantum.
-
-  When the implementation detects that a RR task has been executing for a time
-  larger than or equal to its round robin quantum, the task is said to have
-  exhausted its budget. When the task is next without an inherited priority,
-  and is not executing within a protected operation, it is moved to the tail
-  of the ready queue for its priority level and is given a full quantum.
-
-  A non RR task executing with active priority at a level designated as round
-  robin follows the rules for FIFO_Within_Priorities: if blocked it goes to
-  the back of the associated ready queue; if preempted it goes to the front
-  of the ready queue. It is not subject to the rules concerning the exhaustion
-  of budget of RR tasks.
+o A task that has its base priority set, via the use of Set_Priority,
+  is moved to the tail of the ready queue and given a budget equal to the
+  quantum for the new priority level.
+
+o When a task has an active priority higher than its base priority it is
+  given an infinite quantum at its action priority level; its base priority
+  budget is still decreased when it executes.
+
+o When a task has exhausted its budget, and is without an inherited
+  priority (and is not executing within a protected operation), it is moved
+  to the tail of the ready queue for its priority level and is given a budget
+  equal to the quantum for its priority level. This is a task dispatching point.
 
 Documentation Requirement
 
 An implementation shall document the range of quantum supported, or the
-distinct values supported. Also the maximum priority that can be given to
-Round_Robin_Within_Priorities.
+distinct values supported.
 
 An implementation shall document the accuracy with which it detects the
 exhaustion of a task's budget.
 
-Imlementation Permissions
+Notes
 
-The implementation is allowed to reject a partition if it cannot support
-Round Robin dispatching for the priority requested.
+Due to implementation constraints, the quantum value returned by a call of
+Actual_Quantum may not be identical to that set by a call of Set_Quantum.
 
-Implementation Advice
+A task that executes continuously with an inherited priority will not
+be subject to round robin dispatching.
 
-An implementation will implement round robin dispatching using a
-quantum as close as possible to that given in the Priority_Policy
-pragma.
+Add a new section:
+
+D.2.7 Priority Specific Dispatching
+
+This clause defines the policy_identifier, Priority_Specific,
+the pragma Priority_Specific_Dispatching and package
+Priority_Specific_Dispatching.
+
+Syntax
 
+The form of a pragma Priority_Specific_Dispatching is as follows:
 
+pragma Priority_Specific_Dispatching (policy_identifier,
+          first_priority_expression, last_priority_expression);
+
+
+Name Resolution Rules
+
+The expected type for first_priority_expression and
+last_priority_expression is integer.
+
+Legality Rules
+
+The policy_identifier shall be FIFO_Within_Priorities,
+Round_Robin_Within_Priorities, EDF_Across_Priorities or an
+implementation-defined identifier.
+
+Both first_priority_expression and last_priority_expression
+shall be static expressions in the range of System.Any_Priority;
+last_priority_expression shall have a value greater or equal to
+first_priority_expression.
+
+Post-Compilation Rules
+
+A Priority_Specific_Dispatching pragma is a configuration pragma.
+
+If the Priority_Specific task dispatching policy is specified for a
+partition, then the Ceiling_Locking policy (see D.3) shall also be
+specified for the partition.
+
+The priority ranges specified in more than one Priority_Specific_Dispatching
+pragma within the same partition shall not be overlapping.
+
+If pragma Priority_Specific_Dispatching appears in a partition then the
+Task_Dispatching_Policy shall be Priority_Specific.
+
+Static Semantics
+
+The following language-defined library package exist:
+
+with System;
+package Ada.Dispatching.Priority_Specific_Dispatching is
+  type Dispatching_Policy is (FIFO_Within_Priorities,
+            Round_Robin_Within_Priorities,
+            EDF_Across_Priorities, Other);
+  function Policy(Pri : System.Any_Priority) return Dispatching_Policy;
+end Ada.Dispatching.Priority_Specific_Dispatching;
+
+At all priority levels, the default Priority_Policy is
+FIFO_Within_Priorities.
+
+When Priority_Specific dispatching is in effect, tasks within the
+range of priorities specified in a Priority_Specific_Dispatching pragma
+are dispatched according to the specified dispatching policy.
+
+Dynamic Semantics
+
+When task dispatching policy Priority_Specific 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.
+
+A call of Policy returns the task dispatching policy in effect for
+the specified priority, Pri; Other is returned if an implementation
+defined policy is in effect.
+
+A task that has its base priority changed, via the use of Set_Priority,
+may move from one dispatching policy to another. It is immediately
+dispatched according to the new policy.
+
+A call of Ada.Dispatching.Round_Robin_Dispatching.Set_Quantum with a
+priority Pri (or priority range Low..High) has no effect on priority
+levels that are not covered by policy Round_Robin_Within_Priorities.
+A call of Ada.Dispatching.Round_Robin_Dispatching.Actual_Quantum with
+a priority Pri not covered by policy Round_Robin_Within_Priorities will
+return Ada.Real_Time.Time_Span_Last.
+
+If task dispatching policy EDF_Across_Priorities is in effect for any
+range of priorities then all tasks have deadline Default_Deadline (defined
+in D.2.6) unless modified by pragma Relative_Deadline or calls of
+Set_Deadline or Set_Relative_Deadline (see D.2.6).
+
+If EDF_Across_Priorities is defined for any priority range Low..High then
+the properties assigned to priority System.Any_Priority'first in the
+definition of dispatching policy EDF_Across_Priorities are assigned to
+priority Low for that range of priorities.
+
+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.
+
 !example
 
 pragma Task_Dispatching_Policy (Priority_Specific);
-pragma Priority_Policy (Round_Robin_Within_Priorities, 10, 10, 50.0);
+pragma Priority_Specific_Dispatching (Round_Robin_Within_Priorities, 10, 10);
 
 !discussion
+
+[Open Issue: For Round Robin on its own is it necessary to have ceiling
+locking?]
 
-The rule concerning budget exhaustion gives the important details of the proposal.
+For the Round Robin proposal: the rule concerning budget exhaustion
+gives the important details of the proposal.
 First it is the base priority of a task that is significant.
 If a task's base priority is at a round robin level then it will
-consume its budget whenever it is executing even when
-it has inherited a higher priority (i.e. its active priority is greater than
-its base priority). The fifth rule also deals with the key question of what happens
+consume its budget whenever it is executing even when it has inherited
+a higher priority (i.e. its active priority is greater than its base
+priority). The final rule also deals with the key question of what happens
 if the budget becomes exhausted while executing in a protected object. To
 ensure mutual exclusion, without requiring a further lock, it is necessary to
 allow the task to keep executing within the PO. It will consume more than its
-quantum but the expected behaviour of system is maintained. The usual
+quantum but the expected behaviour of the system is maintained. The usual
 programming discipline of keeping the code within protected objects as short as
 possible will ensure that quantum overrun is minimised. Further support for
 these semantics comes from observing that execution within a PO is

Questions? Ask the ACAA Technical Agent