!standard D.13(8/3) 13-01-03 AI12-0055-1/01 !standard D.13(9/3) !class binding interpretation !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. !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. One way to define such a pragma would be similar to the pragma Partition_Elaboration_Policy (see H.6). [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.] !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. ****************************************************************