CVS difference for ais/ai-00298.txt

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

--- ais/ai-00298.txt	2003/11/27 02:01:15	1.8
+++ ais/ai-00298.txt	2004/05/29 00:38:37	1.9
@@ -1,4 +1,4 @@
-!standard D.2.4 (00)                                   03-02-19  AI95-00298/04
+!standard D.2.4 (00)                                   04-05-24  AI95-00298/05
 !reference AI95-00321
 !class amendment 02-06-01
 !status Amendment 200Y 03-07-02
@@ -46,7 +46,7 @@
 
 D.2.4 Non-Preemptive Dispatching
 
-A non-preemptive dispatching policy is defined via policy_identifier
+A non-preemptive dispatching policy is defined by policy_identifier
 Non_Preemptive_FIFO_Within_Priorities.
 
 Legality Rules
@@ -56,7 +56,7 @@
 
 Post-Compilation Rules
 
-If the Non_Preemptive_FIFO_Within_Priorities is specified for a
+If Non_Preemptive_FIFO_Within_Priorities is specified for a
 partition then Ceiling_Locking (see D.3) shall also be specified
 for that partition.
 
@@ -69,7 +69,7 @@
 ready queue for its active priority.
 
 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
+or the setting of its base priority takes effect, the task is removed
 from the ready queue for its old active priority and is added at the
 tail of the ready queue for its new active priority.
 
@@ -80,25 +80,102 @@
 Implementation Permission
 
 Since implementations are allowed to round all ceiling priorities in
-subrange System_Priority to System_Priority'last (see D.3), 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.
 
 !discussion
 
-The implementation permission is valid as Tasking_Error cannot be
-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.
+Three recent meetings of the International Real-Time Ada Workshop (IRTAW)
+considered a non-preemptive version of Ravenscar, and non-preemptive
+execution in general. Class A (or Class 1) software (as defined
+in safety standards such as DO-178B) typically has a very
+restricted architecture. Often only periodic behaviours need
+be supported. In order to reduce non-determinism and to increase
+the effectiveness of testing, non-preemptive execution is desirable.
 
+The standard way of implementing many high-integrity applications is
+with a cyclic executive. Using this technique a sequence of procedures is
+called within a defined time interval. Each procedure runs to completion and
+there is no concept of preemption. Data is passed from one procedure
+to another via shared variables and no synchronization constraints are
+needed, since the procedures never run concurrently.
+
+The development of the Ravenscar profile has shown how a simple
+subset of the tasking features of Ada can give effective support
+to high-integrity real-time systems. Whilst many system builders are
+prepared to move to use tasking (as defined by Ravenscar) some are
+reluctant to embrace the preemptive dispatching policy. They prefer
+the greater determinism of non-preemptive dispatching.
+
+One of the advantages of non-preemption is that, on a single processor,
+shared data does not require any form of lock to furnish mutual
+exclusion - provided the task does not block within the critical section.
+Ada defines the code within a protected object (PO) to be free of
+potential suspension. Hence POs remain the means of defining critical
+sections of code.
+
+The major disadvantage with non-preemption is that it will
+usually (although not always) lead to reduced schedulability.
+For example, consider a low priority (long deadline) task with a long
+execution time. Once it starts executing, no high priority (short
+deadline) task will be able even to start its execution until the low
+priority task has finished. This is an example of excessive priority
+inversion. To reduce its impact the low priority task needs to
+periodically offer to be preempted. Within Ada the obvious way
+to do this is to execute "delay 0.0" (or delay until "yesterday").
+This technique is known as `deferred preemption' or `co-operative
+scheduling'. At least one major industrial user of Ada employs
+co-operative scheduling and is looking to see it standardized in
+the Standard. Note that non-preemptive behavior does not preclude
+interrupts either for the run-time system (to manage the delay queue) or
+for application-level interrupt handlers.
+
+The definition of preemption in this AI follows the existing definition
+of FIFO_Within_Priority with the absence of the significant rule that
+a task switch must occur if a higher priority task is on a non-empty
+ready queue. Without this rule the current executing task will continue
+to execute unless it blocks, terminates or executes a delay statement.
+
+The implementation permission allows the run-time system to ignore
+entries to and exits from protected objects. No priority changes need
+occur as preemption cannot occur during the time in which a task
+is executing within a normal (non-interrupt level) PO. This can
+lead to a very efficient implementation.
+
+The above definitions have centred 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 since
+Ada only allows the dispatching policy within a partition to be defined,
+no further refinement of the language model can be given.
+
+Full motivation and details of the scheduling analysis that can be
+applied to non-preemptive dispatching are contained in:
+A. Burns, Defining New Non-Preemptive Dispatching
+and Locking Policies for Ada, Proceedings of Reliable Software
+Technologies - Ada Europe 2001, LNCS, pp328-336, 2001.
+
 !example
 
 !corrigendum D.2.4(01)
 
 @dinsc
 
-A non-preemptive dispatching policy is defined via @i<policy_>@fa<identifier>
+A non-preemptive dispatching policy is defined by @i<policy_>@fa<identifier>
 Non_Preemptive_FIFO_Within_Priorities.
 
 @i<@s8<Legality Rules>>
@@ -108,7 +185,7 @@
 
 @i<@s8<Post-Compilation Rules>>
 
-If the Non_Preemptive_FIFO_Within_Priorities is specified for a
+If Non_Preemptive_FIFO_Within_Priorities is specified for a
 partition then Ceiling_Locking (see D.3) shall also be specified
 for that partition.
 
@@ -121,7 +198,7 @@
 ready queue for its active priority.>
 
 @xbullet<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
+or the setting of its base priority takes effect, the task is removed
 from the ready queue for its old active priority and is added at the
 tail of the ready queue for its new active priority.>
 
@@ -132,7 +209,7 @@
 @i<@s8<Implementation Permissions>>
 
 Since implementations are allowed to round all ceiling priorities in
-subrange System_Priority to System_Priority'last (see D.3), 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.

Questions? Ask the ACAA Technical Agent