!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.

****************************************************************