CVS difference for ai05s/ai05-0171-1.txt

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0171-1.txt

--- ai05s/ai05-0171-1.txt	2010/02/23 22:11:00	1.3
+++ ai05s/ai05-0171-1.txt	2010/06/13 01:45:07	1.4
@@ -1,28 +1,33 @@
-!standard  D.13.1(4/2)                             10-02-23    AI05-0171-1/03
+!standard  D.13.1(4/2)                             10-06-04    AI05-0171-1/04
 !standard  D.16
 !class Amendment 09-10-22
 !status work item 09-10-22
 !status received 09-10-22
 !priority Medium
 !difficulty Easy
-!subject Ravenscar Profile for Multiprocessor Systems
+!subject Pragma CPU and Ravenscar Profile
 
 !summary
 
 The Ravenscar Profile, originally designed for single processors, has
 proven remarkably useful for modelling verifiable real-time
 single-processor systems. It can be extended to support
-multi-processor systems using a fully partitioned approach. The
+multiprocessor systems using a fully partitioned approach. The
 implementation of this scheme is simple, and it can be used to develop
 applications amenable to schedulability analysis.
 
+To specify the required Ravenscar behaviour on a multiprocessor
+platform requires the definition of a pragma that will statically
+set the affinity of a task. This pragma has utility outside its
+use with the Ravenscar profile.
+
 !problem
 
 The Ravenscar Profile defines a deterministic and analysable tasking
 model for single processors which can be supported with a run-time
-system of reduced size and complexity. For multi-processor systems,
+system of reduced size and complexity. For multiprocessor systems,
 the Ravenscar Profile could be extended using a fully partitioned
-approach, with each task allocated statically to a concrete processor.
+approach, with each task allocated statically to a physical processor.
 This scheme could be supported by a streamlined run-time system, and
 applications built following this approach can apply timing analysis
 techniques on each processor separately.
@@ -30,10 +35,12 @@
 !proposal
 
 We propose to allow the implementation of the Ravenscar Profile on
-multi-processor systems following a fully partitioned approach.
+multiprocessor systems following a fully partitioned approach.
+
+The first part of the proposal contains the definition of a
+pragma for controlling task affinity, a general package is
+then defined that will be used by the Ravenscar profile.
 
-The first part of the proposal is a general package that will
-be used by Ravenscar.
 
 !wording
 
@@ -53,23 +60,24 @@
 
 Name Resolution Rules
 
-The expected type for the expression is Integer.
+The expected type for the expression is System.Multiprocessors.CPU_Range.
 
 A CPU pragma is allowed only immediately within a task_definition, or the
 declarative_part of a subprogram_body. At most one such pragma shall appear
 within a given construct.
 
 For a CPU pragma that appears in the declarative_part of a subprogram_body,
-the expression shall be static, and its value shall be in the range of
-System.Multiprocessors.CPU.
+the expression shall be static.
 
 
 Static Semantics
 
-The following language-defined library package exists
+The following language-defined library package exists:
 
    package System.Multiprocessors is
-      type CPU_Range is range 0 .. <implementation-defined>
+      pragma Preelaborate(Multiprocessors);
+      type CPU_Range is range 0 .. <implementation-defined>;
+      Not_A_Specific_CPU : constant CPU_Range := 0;
       subtype CPU is CPU_Range range 1 .. CPU_Range'last;
       function Number_Of_CPUs return CPU;
    end System.Multiprocessors;
@@ -78,36 +86,57 @@
 Dynamic Semantics
 
 A CPU pragma has no effect if it occurs in the declarative part of the
-subprogram_body of a subprogram other then the main subprogram.
+subprogram_body of a subprogram other than the main subprogram.
 
 The CPU value determines the processor on which the task will
-activate and execute. A task without a pragma will execute on the same
-processor as its activating task. It is implementation defined where the
-environment task executes.
+activate and execute; the task is said to be assigned to
+that processor. If the CPU value is Not_A_Specific_CPU
+then the task is not assigned to a processor.
+A task without a CPU pragma will activate and execute on the same
+processor as its activating task if the activating task is assigned
+a processor. If the CPU value is not in the range of
+System.Multiprocessors.CPU_Range or is greater than Number_Of_CPUs
+the task is defined to have failed, and it becomes a completed task (see
+9.2(1)).
+
+The CPU value is associated with the environment task if the pragma
+appears in the declarative_part of the main subprogram. If a pragma
+CPU does not apply to the main subprogram it is implementation defined
+where the environment task executes.
 
 A call of Number_Of_CPUs returns the number of processors available
-to the program.
+to the program. Within a given partition, each call on Number_Of_CPUs
+will return the same value.
 
 ---
 
 
 Add to D.13.1(4/2) a new restriction:
+
+No_Dependence => System.Multiprocessors.Dispatching_Domains;
 
-No_Dependence => System.Multiprocessors.Dispatching_Policies;
+[Should there be a new restrictions_parameter Max_Dispatching_Domains
+set to 1 for Ravenscar]
 
 ---
 Add after D.13.1(4/2):
 
+Implementation Requirements
+
+A task shall only be on the ready queues of one processor, and the
+processor to which a task belongs shall be defined statically.
+Whenever a task running on a processor reaches a task dispatching point,
+it goes back to the ready queues of the same processor. A task with
+a CPU value of Not_A_Specific_CPU will execute on an implementation
+defined processor. A task without a CPU pragma will activate and execute
+on the same processor as its activating task.
+
+
 Implementation Advice
 
-On a multi-processor system, an implementation should support a fully
-partitioned approach, with each task allocated statically to a
-concrete processor and no task migration. Each processor should have
-separate and disjoint ready queues. A task should only be on the ready
-queues of one processor, and the processor to which a task belongs
-should be defined statically. Whenever a task running on a processor
-reaches a task dispatching point, it goes back to the ready queues of
-the same processor.
+On a multiprocessor system, an implementation should support a fully
+partitioned approach. Each processor should have separate and disjoint
+ready queues.
 
 
 !discussion
@@ -122,10 +151,10 @@
 
 !example
 
-A task type that defines worker tasks to be allocated to different CPUs 
+A task type that defines worker tasks to be allocated to different CPUs
 would have the form:
 
-   task type Worker (W : integer) is
+   task type Worker (W : CPU_Range) is
       pragma CPU(W);
    end Worker;
 

Questions? Ask the ACAA Technical Agent