!standard D.7(10/3) 14-09-29 AI12-0055-1/06 !standard D.13(6/3) !standard D.13(8/3) !standard D.13(10/3) !class binding interpretation 12-12-08 !status Corrigendum 1-2012 14-07-11 !status WG9 Approved 14-10-20 !status ARG Approved 9-0-0 13-06-27 !status work item 12-12-08 !status received 12-12-08 !priority Medium !difficulty Medium !qualifier Omission !subject All properties of a usage profile are defined by pragmas !summary The application of the Ravenscar Profile to multiprocessors requires one new configuration pragma and one new restriction to be defined to ensure that all tasks are assigned to a CPU. !question The definition of a profile says (13.12(13/3)): A profile is equivalent to the set of configuration pragmas that is defined for each usage profile. However, the Ravenscar profile has rules (D.13.1(8-9/3)) that are not associated with any configuration pragma. Should one be defined? (Yes.) !recommendation (See !summary.) !wording Add a new restriction after D.7(10/3): No_Dynamic_CPU_Assignment No task has the CPU aspect specified to be a non-static expression. Each task (including the environment task) that has the CPU aspect specified as Not_A_Specific_CPU will be assigned to a particular implementation-defined CPU. The same is true for the environment task when the CPU aspect is not specified. [Redundant:Any other task without a CPU aspect will activate and execute on the same processor as its activating task.] AARM Proof: The processor of a task without a CPU aspect is defined in D.16, and this restriction guarantees that the activator always has a CPU assigned. AARM Reason: This restriction prevents any migration of tasks. AARM Ramification: If no CPU aspects are specified, then the program will run on a single CPU, as all of the tasks will be activated directly or indirectly by the environment task, and the rules require the same CPU to be used as the activating task. AARM Implementation-defined: When restriction No_Dynamic_CPU_Assignment applies to a partition, the processor on which a task with a CPU value of a Not_A_Specific_CPU will execute. Add to D.13(6/4), after No_Dynamic_Attachment: No_Dynamic_CPU_Assignment, Delete D.13(8/3) and the associated AARM notes. Add after D.13(10/3) [Notes]: When the Ravenscar profile is in effect (via the effect of the No_Dynamic_CPU_Assignment restriction), all of the tasks in the partition will execute on a single CPU unless the programmer explicitly uses aspect CPU to specify the CPU assignments for tasks. The use of multiple CPUs requires care, as many guarantees of single CPU scheduling no longer apply. It is not recommended to specify the CPU of a task to be Not_A_Specific_CPU when the Ravenscar profile is in effect. How a partition executes strongly depends on the assignment of tasks to CPUs. !discussion During the discussion of AI12-0048-1, it was pointed out that Ravenscar has special rules for the assignment of tasks to processors. These rules appear to require that FIFO_within_Priorities scheduling be ineffective on Ravenscar programs (as it appears impossible in general for the implementation to assign tasks such that unbounded priority inversion cannot occur]). [That is possible for some systems of tasks and priorities, and it can often be done by hand, but the rules require the system to do it automatically.] It was felt by some that hiding such a significant change to the priority model in an Implementation Requirement is far too subtle. At this point, it was noted that Ravenscar is a profile, which is just a collection of pragmas. But the behavior of D.13(8-9/3) is not tied to any pragma. This is wrong. Moreover, by defining it as a pragma, both the rules and the effects would be more visible. To fix this we add a new restriction No_Dynamic_CPU_Assignment. We add this restriction to the Ravenscar profile. D.13(8/3) is deleted; it follows from other rules. The text about "ready queues" is obvious (it's the definition of assigning a CPU to a task); and the Not_A_Specific_CPU text is moved to the new restriction, along with the redundant text. We also add user notes to the Ravenscar profile to note that a Ravenscar program will always run on a single CPU unless the programmer takes action with aspect CPU to define otherwise. We also caution against specifying tasks to have Not_A_Specific_CPU. --- It's possible that this new restriction is incompatible with existing implementations. However, that could only be because they ignored D.13(8/3)'s requirement that "the processor be defined statically"; specifying a CPU aspect with a non-static value could not meet that requirement. !corrigendum D.7(10/3) @dinsa @xhang<@xterm There is no use of a @fa denoting any of the operations defined in package Interrupts (Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler, Detach_Handler, and Reference).> @dinst @xhang<@xterm No task has the CPU aspect specified to be a non-static expression. Each task (including the environment task) that has the CPU aspect specified as Not_A_Specific_CPU will be assigned to a particular implementation-defined CPU. The same is true for the environment task when the CPU aspect is not specified. Any other task without a CPU aspect will activate and execute on the same processor as its activating task.> !corrigendum D.13(6/3) @drepl @xcode<@b Task_Dispatching_Policy (FIFO_Within_Priorities); @b Locking_Policy (Ceiling_Locking); @b Detect_Blocking; @b 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_Budgets, No_Dependence =@> Ada.Execution_Time.Timers, No_Dependence =@> Ada.Task_Attributes, No_Dependence =@> System.Multiprocessors.Dispatching_Domains);> @dby @xcode<@b Task_Dispatching_Policy (FIFO_Within_Priorities); @b Locking_Policy (Ceiling_Locking); @b Detect_Blocking; @b Restrictions ( No_Abort_Statements, No_Dynamic_Attachment, No_Dynamic_CPU_Assignment, 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_Budgets, No_Dependence =@> Ada.Execution_Time.Timers, No_Dependence =@> Ada.Task_Attributes, No_Dependence =@> System.Multiprocessors.Dispatching_Domains);> !corrigendum D.13(8/3) @ddel 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 aspect will activate and execute on the same processor as its activating task. !corrigendum D.13(10/3) @dinsa @xindent<@s9 1 restriction applies only to protected entry queues due to the accompanying restriction of Max_Task_Entries =@> 0.>> @dinss @xindent<@s9<43 When the Ravenscar profile is in effect (via the effect of the No_Dynamic_CPU_Assignment restriction), all of the tasks in the partition will execute on a single CPU unless the programmer explicitly uses aspect CPU to specify the CPU assignments for tasks. The use of multiple CPUs requires care, as many guarantees of single CPU scheduling no longer apply.>> @xindent<@s9<44 It is not recommended to specify the CPU of a task to be Not_A_Specific_CPU when the Ravenscar profile is in effect. How a partition executes strongly depends on the assignment of tasks to CPUs.>> !ACATS Test Create an ACATS C-Test to check the existence of the new pragma. !appendix This AI was created out of discussion on AI12-0048-1 during ARG meeting #48 in Boston. **************************************************************** From: Alan Burns Sent: Thursday, May 30, 2013 8:18 AM There has been discussions on these AIs from within the IRTAW 'community'. Our views are as follows (note we also looked at AI-0048 as well). ... [Only relevant part here - Editor.] For Ravenscar the intent is that all tasks are statically allocated to CPUs (and there is just one Dispatching Domain). And as a Profile, the intent must be indicated by pragmas (that are then incorporated into the Profile). The simplest way to enforce static allocation is to: 1) Introduce a configuration pragma that assigns a CPU to the environment task, and for Ravenscar, perhaps, force this CPU to be number 1. All program tasks would then run on the same CPU as the environment task unless they used the CPU aspect. This is safe unless they used 'Not_A_Specific_CPU'. So 2) Introduce a pragma that prevents the use of Not_A_Specific_CPU. These two pragmas should then be added to the Ravenscar Profile. So if the programmer does nothing else all tasks will run on CPU 1, but they can use the CPU aspect to do the allocation (just as they assign priorities). There is some discussion in the AI about priority inversion. For static task allocation (as in Ravenscar) this is not an issue. It is clear from the definition of the dispatching model that conceptually all processors have a distinct set of ready queues. So yes a middle priority task on one CPU can be preempted while a low priority task on another CPU is running, but that is exactly what is expected. Now to the Implementation Advice D.13.9/3 Here we think this should remain as Advice. It is really just saying that the conceptual model of a set of ready queues per processor should form the basic of the actual implementation. Good advice, but not enforceable in the language I hope this clears up the points raised (no doubt there will be more). Tullio will be at the ARG meeting. ****************************************************************