CVS difference for ais/ai-00298.txt

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

--- ais/ai-00298.txt	2002/07/23 01:05:25	1.2
+++ ais/ai-00298.txt	2002/08/24 03:54:24	1.3
@@ -1,4 +1,4 @@
-!standard D.8 (00)                                     02-06-01  AI95-00298/01
+!standard D.8 (00)                                     02-08-01  AI95-00298/02
 !class amendment 02-06-01
 !status work item 02-06-01
 !status received 02-06-01
@@ -8,8 +8,8 @@
-A new dispatching policy and locking policy are defined for the
-non-preemptive execution of Ada tasks.
+A new dispatching policy is defined for the non-preemptive execution
+of Ada tasks.
@@ -32,23 +32,18 @@
-Two new policy identifiers are defined, namely Non_Preemptive_FIFO_
-Within_Priorities and Non_Preemptive_Locking. These are task dispatching
-policies and locking policies respectively and are used with the existing
-pragmas thus:
+A new task dispatching policy is defined, namely Non_Preemptive_FIFO_
+Within_Priorities. It uses the existing pragmas thus:
 pragma Task_Dispatching_Policy (
-pragma Locking_Policy (Non_Preemptive_Locking);
+This policy is optional.
-These policies are optional.
 Post-Compilation Rules
-If the Non_Preemptive_Locking policy is specified for a partition then
-Non_Preemptive_FIFO_Within_Priorities shall also be specified for that
+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
@@ -87,19 +82,6 @@
   the execution token. Note this can only occur in a multiprocessor
-The locking policy, Non_Preemptive_Locking is defined as follows:
-- if the protected object contains any of the following three pragmas:
-  Interrupt_Priority, Interrupt_Handler or Attach_Handler then the rules
-  defined for locking policy Ceiling_Locking apply;
-- if none of the above pragmas are present then, on a single processor,
-  no run-time code need be generated to protect the object, in particular
-  the priority of the calling task need not be changed;
-- pragma Priority must not be present in any protected object (an
-  alternative would be to say that pragma Priority has no effect).
 * The running task may release the execution token by issuing a relative
@@ -124,9 +106,25 @@
   task waiting for access to a protected agent keeps the processor
   busy (i.e. retains the execution token), see D.2.1(3).
+New subclause:
+D.2.3 A Non-Preemptive Task Dispatching Policy
+would include the text above and
+Implementation Permission
+Since implementations are allowed to round all ceiling priorities in
+subrange System_Priority to System_Priority'last (see D.3 (14)), 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.
 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
@@ -147,6 +145,33 @@
 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.
+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.
+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).

Questions? Ask the ACAA Technical Agent