!standard D.13(8/3) 13-06-08 AI12-0055-1/02 !standard D.13(9/3) !class binding interpretation 12-12-08 !status work item 12-12-08 !status received 12-12-08 !priority Medium !difficulty Medium !qualifier Omission !subject All properties of a profile are defined by pragmas !summary ** TBD. !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 ** TBD. See the discussion for the intent. !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 of 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. We actually choose to define two pragmas. [Note: Names and exact semantics TBD.] First, we define a configuration pragma that assigns a CPU to the environment task. pragma Environment_Task_CPU (expression); The expression is a CPU. (Get wording from J.15.7 and D.16). The meaning is the same as pragma CPU given in the main subprogram (but of course it can be given separately from the main subprogram). Second, we add a new restriction: No_Not_A_Specific_CPU Use of Not_A_Specific_CPU is not allowed in aspect CPU or pragma CPU. [Should this also apply to parameters of calls to the Dispatching_Domain package? That can't happen for Ravenscar, but it would make sense for a stand-alone restriction.] The profile Ravenscar is enhanced with pragma Environment_Task_CPU (1); and No_Not_A_Specific_CPU is added to the list of restrictions in an appropriate place. Finally, D.13(8/3) is deleted; it follows from other rules. [Should there be a user note discussing this? With this definition, a Ravenscar program will always run on a single CPU unless the programmer takes action with aspect CPU to define otherwise. 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 OBE, so we'd need a more relevant discussion.] We also need to update the list of ways to specify the assignment of a task in AARM D.16.1(30.d/4), added by AI12-0048-1, to include Environment_Task_CPU. ** Old text, probably to delete: [Editor's musings (not veted by anyone): I'm pretty certain that it is not possible in general to assign tasks statically to processors and still ensure that no priority inversion occurs. It might be possible if no task's active priority changed during execution (I'm not completely convinced), but once priority changes caused by application of ceiling priorities are involved, we have dynamic priority changes and the implementation cannot reasonably know about which changes are possible. (It's clear that many systems will be analyzed by tools or humans and can be proved to have no priority inversion problems with a particular assignment, but of course the language has to work for *anything* submitted to it, reasonable or not.) As such, it seems dangerous to me to require the implementation to *automatically* assign tasks to processors when it cannot maintain the guarentees made by FIFO_Within_Priorities (which is an integral part of the Ravenscar profile). So I would suggest requiring manual assignment (via aspect CPU) whenever those guarentees cannot be maintained. Clearly, there are cases where no problem is possible (no priorities, or no more tasks than processors), and it is OK to do automatic assignment in those cases. Thus, I think IRTAW should consider requiring rejection of programs where automatic assignment is unsafe - or some other semantics which is safe, in the absence of the setting of the CPU aspect.] [Comment on the above, based on the current solution: essentially, IRTAW is requiring manual assignment of tasks, which eliminates the above concern (it also eliminates the requirement that started this discussion).] !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. ****************************************************************