Version 1.5 of ai05s/ai05-0171-1.txt
!standard D.13.1(4/2) 10-08-12 AI05-0171-1/05
!standard D.16
!class Amendment 09-10-22
!status Amendment 2012 10-08-12
!status ARG Approved 8-0-2 10-06-18
!status work item 09-10-22
!status received 09-10-22
!priority Medium
!difficulty Easy
!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
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 multiprocessor systems,
the Ravenscar Profile could be extended using a fully partitioned
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.
!proposal
We propose to allow the implementation of the Ravenscar Profile on
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.
!wording
Add a new clause:
D.16 Multiprocessor Implementation
This clause allows implementations on multiprocessor platforms to
be configured.
Static Semantics
The following language-defined library package exists:
package System.Multiprocessors is
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;
A call of Number_Of_CPUs returns the number of processors available
to the program. Within a given partition, each call on Number_Of_CPUs
will return the same value.
Syntax
The form of a pragma CPU is as follows:
pragma CPU (expression);
Name Resolution Rules
The expected type for the expression is System.Multiprocessors.CPU_Range.
Legality Rules
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.
Dynamic Semantics
The expression of a CPU pragma that appears in a task_definition is
evaluated for each task object (see 9.1). The CPU value is then associated
with the task object whose task_definition contains the pragma.
Elaboration of a CPU pragma given immediately within the declarative_part of a
subprogram_body has no effect; the CPU value is not associated with any
task unless the pragma occurs within the main subprogram.
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 on which processor the environment task executes.
The CPU value determines the processor on which the task will
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).
---
Add to D.13.1(4/2) a new restriction:
No_Dependence => System.Multiprocessors.Dispatching_Domains,
---
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 multiprocessor system, an implementation should support a fully
partitioned approach. Each processor should have separate and disjoint
ready queues.
!discussion
Although there are many dispatching approaches that make use of
task migration this significantly complicates the run-time
and adds overheads. For Ravenscar and its focus on static properties
it is in keeping to disallow migration. The scheduling problem for
partitioned allocation is a combination of bin packing followed
by single processor dispatching. These are known techniques and
do not add complications to the Ravenscar model.
!example
A task type that defines worker tasks to be allocated to different CPUs
would have the form:
task type Worker (W : CPU_Range) is
pragma CPU(W);
end Worker;
Alan : Worker(1);
!corrigendum D.13.1(4/2)
Replace the paragraph:
pragma Task_Dispatching_Policy (FIFO_Within_Priorities);
pragma Locking_Policy (Ceiling_Locking);
pragma Detect_Blocking;
pragma Restrictions (
No_Abort_Statements,
No_Dynamic_Attachment,
No_Dynamic_Priorities,
No_Implicit_Heap_Allocations,
No_Local_Protected_Objects,
No_Local_Timing_Events,
No_Protected_Type_Allocators,
No_Relative_Delay,
No_Requeue_Statements,
No_Select_Statements,
No_Specific_Termination_Handlers,
No_Task_Allocators,
No_Task_Hierarchy,
No_Task_Termination,
Simple_Barriers,
Max_Entry_Queue_Length => 1,
Max_Protected_Entries => 1,
Max_Task_Entries => 0,
No_Dependence => Ada.Asynchronous_Task_Control,
No_Dependence => Ada.Calendar,
No_Dependence => Ada.Execution_Time.Group_Budget,
No_Dependence => Ada.Execution_Time.Timers,
No_Dependence => Ada.Task_Attributes);
by:
pragma Task_Dispatching_Policy (FIFO_Within_Priorities);
pragma Locking_Policy (Ceiling_Locking);
pragma Detect_Blocking;
pragma Restrictions (
No_Abort_Statements,
No_Dynamic_Attachment,
No_Dynamic_Priorities,
No_Implicit_Heap_Allocations,
No_Local_Protected_Objects,
No_Local_Timing_Events,
No_Protected_Type_Allocators,
No_Relative_Delay,
No_Requeue_Statements,
No_Select_Statements,
No_Specific_Termination_Handlers,
No_Task_Allocators,
No_Task_Hierarchy,
No_Task_Termination,
Simple_Barriers,
Max_Entry_Queue_Length => 1,
Max_Protected_Entries => 1,
Max_Task_Entries => 0,
No_Dependence => Ada.Asynchronous_Task_Control,
No_Dependence => Ada.Calendar,
No_Dependence => Ada.Execution_Time.Group_Budget,
No_Dependence => Ada.Execution_Time.Timers,
No_Dependence => Ada.Task_Attributes,
No_Dependence => System.Multiprocessors.Dispatching_Domains);
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 multiprocessor system, an implementation should support a fully
partitioned approach. Each processor should have separate and disjoint
ready queues.
!corrigendum D.16(0)
Insert new clause:
This clause allows implementations on multiprocessor platforms to
be configured.
Static Semantics
The following language-defined library package exists:
package System.Multiprocessors is
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;
A call of Number_Of_CPUs returns the number of processors available
to the program. Within a given partition, each call on Number_Of_CPUs
will return the same value.
Syntax
The form of a pragma CPU is as follows:
pragma CPU (expression);
Name Resolution Rules
The expected type for the expression is System.Multiprocessors.CPU_Range.
Legality Rules
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.
Dynamic Semantics
The expression of a CPU pragma that appears in a task_definition is
evaluated for each task object (see 9.1). The CPU value is then associated
with the task object whose task_definition contains the pragma.
Elaboration of a CPU pragma given immediately within the declarative_part of a
subprogram_body has no effect; the CPU value is not associated with any
task unless the pragma occurs within the main subprogram.
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 on which processor the environment task executes.
The CPU value determines the processor on which the task will
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).
!ACATS test
Add an ACATS C-Test of this package.
!appendix
****************************************************************
Questions? Ask the ACAA Technical Agent