CVS difference for ais/ai-00298.txt

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

--- ais/ai-00298.txt	2002/08/24 03:54:24	1.3
+++ ais/ai-00298.txt	2003/01/16 01:37:17	1.4
@@ -1,4 +1,4 @@
-!standard D.8 (00)                                     02-08-01  AI95-00298/02
+!standard D.8 (00)                                     03-01-06  AI95-00298/03
 !class amendment 02-06-01
 !status work item 02-06-01
 !status received 02-06-01
@@ -33,146 +33,66 @@
 !proposal
 
 A new task dispatching policy is defined, namely Non_Preemptive_FIFO_
-Within_Priorities. It uses the existing pragmas thus:
+Within_Priorities. It is one of a number of additional task
+dispatching policies. The proposal assumes wording changes have been
+agreed for sections D.2.1 and D.2.2 (see AI95-00321).
 
-pragma Task_Dispatching_Policy (
-	Non_Preemptive_FIFO_Within_Priorities);
+!wording
 
-This policy is optional.
+New section D.14:
 
-Post-Compilation Rules
+D.14 Additional Task Dispatching Policies
 
-If the Non_Preemptive_FIFO_Within_Priorities is specified for a partition then
-Ceiling_Locking (see D.3) shall also be specified for that partition.
+This clause specifies additional task dispatching policies.
 
-Dynamic Semantics
+D.14.1 Non-Preemptive Dispatching
 
-In accordance with implementation permission D.2.1(9) an additional
-execution resource, the execution token, is defined.
+A non-preemptive dispatching policy is defined via policy_identifier
+Non_Preemptive_FIFO_Within_Priorities.
 
-Each processor has one such execution token.
+Syntax
 
-A ready task must acquire the execution token before it can become the
-running task. When the Non_Preemptive_FIFO_Within_Priorities policy is
-in effect the modifications to the ready queues are identical to the
-existing preemptive policy FIFO_Within_Priorities.
+pragma Task_Dispatching_Policy (
+	Non_Preemptive_FIFO_Within_Priorities);
 
-The running task releases the execution token whenever it becomes suspended
-(or completed). It also releases the execution token whenever it
-executes a delay statement (whether this results in suspension or not).
-A new running task is selected and is assigned the execution token whenever
-the previously running task on that processor becomes suspended or otherwise
-releases the execution token. The rule for selecting the new
-running task follows the policy of Fifo_Within_Priorities.
-On a multiprocessor system there may be further restrictions on
-where tasks may execute (as covered in D.2.1(15)).
-
-To cover asynchronous task interactions the following rules apply:
-
-o If a task holding an execution token is aborted it releases the
-  execution token when it completes.
-
-o If a task holding an execution token executes a select-then-abort
-  construct, and the trigger occurs, then the aborted construct is
-  completed following the rules of D.6 but the token is retained.
-
-o If a task holding an execution token is subject to a priority
-  change (as a consequence of a call to Set_Priority, D.5) or asynchronous
-  control (as a consequence of a call to Hold, D.11) then it retain
-  the execution token. Note this can only occur in a multiprocessor
-  implementation.
-
-NOTE:
-
-* The running task may release the execution token by issuing a relative
-  delay with a nonpositive duration or an absolute delay using a time in
-  the past, but be reassigned the token immediately if it is at the head
-  of the highest priority ready queue.
-
-* Implementation Permission 9.5.3 (22) still applies.
-
-* It remains a bounded error to call a potentially blocking operation
-  from within a protected object.
-
-* A task executing an accept statement on which there is an
-  outstanding call, proceeds without releasing the execution
-  token (either before or after the execution of the accept statement).
-  Select statements are treated similarly.
-
-* A task calling an entry of a task releases the execution token even
-  if the entry is open.
-
-* It remains implementation defined, on a multiprocessor, whether a
-  task waiting for access to a protected agent keeps the processor
-  busy (i.e. retains the execution token), see D.2.1(3).
+Post-Compilation Rules
 
-!wording
+If the Non_Preemptive_FIFO_Within_Priorities is specified for a
+partition then Ceiling_Locking (see D.3) shall also be specified
+for that partition.
+
+Dynamic Semantics
 
-New subclause:
+When Non_Preemptive_FIFO_Within_Priorities is in effect, modifications
+to the ready queues occur only as follows:
 
-D.2.3 A Non-Preemptive Task Dispatching Policy
+o When a blocked task becomes ready, it is added at the tail of the
+ready queue for its active priority.
 
-would include the text above and
+o When the active priority of a ready task that is not running changes,
+or the setting of its base priority takes effect, the task is moved
+from the ready queue for its old active priority and is added at the
+tail of the ready queue for its new active priority.
+
+o When a task executes a delay_statement that does not result in
+blocking, it is added to the tail of the ready queue for its active
+priority. This is a task dispatching point (see D.2.1).
 
 Implementation Permission
 
 Since implementations are allowed to round all ceiling priorities in
-subrange System_Priority to System_Priority'last (see D.3 (14)), an
+subrange System_Priority to System_Priority'last (see D.3), an
 implementation may allow a task to execute within a protected object
 without raising its active priority provided the protected object does
-not contain pragma Interrupt_Priority, Interrupt_Handler or Attach_Handler.
+not contain pragma Interrupt_Priority, Interrupt_Handler or Attack_Handler.
 
 !discussion
 
-(a)
-The above definitions have centered on the notion of a processor and
-non-preemptive execution on that processor. In Ada terms, however, this is
-not the complete story. Dispatching policies are set on a per-partition
-basis and it is possible for an implementation to put more than one
-partition on a processor. The standard is silent about multi-partition
-scheduling, and there is clearly more than one way to schedule such a
-system, for example:
-
-o use `priority' across all partitions on the same processor;
-
-o assign overriding priorities to each partition;
-
-o use priority dispatching within a partition and time-slicing
-  between partitions.
-
-The notion of `non-preemption' is different in all three cases. But as
-Ada only allows the dispatching policy within a partition to be defined,
-no further refinement of the language model can be given. It would
-be possible for an implementation to have an execution token per processor
-or per partition.
-
-(b)
 The implementation permission is valid as Tasking_Error cannot be
-raised if all ceiling are rounded to the 'last value.  However this
+raised if all ceiling are rounded to the 'last value. However this
 is only a permission, not a requirement and hence is weaker than
 the earlier proposal.
 
-(c)
-The use of an execution token, rather than a new policy, is required as
-Annex D assumes preemptive execution. D.2.2, the dispatching policy builds
-on the priority scheduling model D.2.1. This model clearly states that
-"processor are preemptible resources" (D.2.1 (7)), and "the task dispatching
-model specifies preemptive scheduling" (D.2.1 (1)).
-
-To make all of D.2.1 'A model' (rather than 'The model') would undermine
-Annex D. Preemption is implicit in a number of places, e.g. D.6 (5),
-D.5 (14), D.9 (12), D.9 (13) and D.1 (15).  The introduction of an execution
-token leaves the processor as a preemptive resource and does seem to be
-the appropriate method as allowed by D.2.1 (9).
-
-Although not covered in this AI, it would be possible to define a policy
-that allowed the coexistence of preemptive and non-preemptive tasks by a
-relatively simple change to the rules defined above for the execution token;
-a completely new scheduling model would not be necessary.
-
-As a final point, the approach taken in this AI could easily be used to
-define a non-interruptible policy (based on a different token).
-
 !examples
 
 !ACATS Test
@@ -204,9 +124,9 @@
 the safety-critical area, the policy of choice is non-preemption.
 
 The standard way of implementing many high-integrity applications is
-with a cyclic executive.  Here a sequence of procedures is called
-within a defined time interval.  Each procedure runs to completion,
-there is no concept of preemption.  Data is passed from one procedure
+with a cyclic executive. Here a sequence of procedures is called
+within a defined time interval. Each procedure runs to completion,
+there is no concept of preemption. Data is passed from one procedure
 to another via shared variables; no synchronization constraints are
 needed since the procedures never run concurrently.
 
@@ -243,7 +163,7 @@
 Each processor has one such execution token.
 
 A ready task must acquire the execution token before it can become the
-running task.  When the Non_Preemptive_FIFO_Within_Priorities policy is
+running task. When the Non_Preemptive_FIFO_Within_Priorities policy is
 in effect the modifications to the ready queues are identical to the
 existing preemptive policy FIFO_Within_Priorities.
 

Questions? Ask the ACAA Technical Agent