Version 1.1 of acs/ac-00241.txt

Unformatted version of acs/ac-00241.txt version 1.1
Other versions for file acs/ac-00241.txt

!standard D.5.1(8)          13-01-08 AC95-00241/00
!standard D.13(6/3)
!class Amendment 13-01-08
!status received no action 13-01-08
!status received 12-11-03
!subject Cannot determine the base priority of a task in Ravenscar
!summary
!appendix

!topic Cannot determine the base priority of a task
!reference Ada 2012 RM D.1(15), D.13 (6/3), D.7 (9/2), 6.1.1 (2/3)
!from Brad Moore 12-09-03
!keywords Ravenscar Priority Precondition
!discussion

There appears to be no way to determine the base priority of a task.
This could be useful, for example to write a precondition on a
protected subprogram to ensure that the priority of the calling task has
an expected value, to avoid problems such as priority inversions.

One can determine the current priority of a task using the
Ada.Dynamic_Priorities.Get_Priority call, but that call cannot be used
in a Ravenscar program, and the current priority is not necessarily the
same as the base priority of a task.

-- How do you do this is Ravenscar?
protected type T (Priority : System.Priority := System.Default_Priority)
with Priority => Priority is

    procedure Foo
      with Pre => Ada.Dynamic_Priorities.Get_Priority = Priority;
end T;

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

From: Tucker Taft
Sent: Sunday, November  4, 2012  9:01 AM

> One can determine the current priority of a task using the
> Ada.Dynamic_Priorities.Get_Priority call, but that call cannot be used
> in a Ravenscar program, and the current priority is not necessarily
> the same as the base priority of a task.

The description of Ada.Dynamic_Priorities.Get_Priority says:

   The function Get_Priority returns T's current base priority.
   Tasking_Error is raised if the task is terminated.

So I am uncertain of your issue.

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

From: Brad Moore
Sent: Sunday, November  4, 2012  11:06 AM

Thanks Tuck, I missed that. However I still have an issue.

In Ravenscar one is not allowed to have any semantic dependence on
Ada.Dynamic_Priorities, see D.7 (9/2). So in Ravenscar there is no way to
determine the base priority of a task. (You'll notice I appended "in Ravenscar"
to the end of the subject of this email. Maybe I should instead submit a new
comment if that makes it easier for tracking purposes)

I can understand why Set_Priority would have been disallowed in Ravenscar, but
it seems the scalpel might have gone too deep to disallow Get_Priority. See the
question in the line below.

>> -- How do you do this is Ravenscar?
>> protected type T (Priority : System.Priority :=
>> System.Default_Priority) with Priority => Priority is
>>
>>     procedure Foo
>>       with Pre => Ada.Dynamic_Priorities.Get_Priority = Priority;
>>     end T;

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

From: Tucker Taft
Sent: Sunday, November  4, 2012  3:20 PM

>>> -- How do you do this is Ravenscar?

I think the answer is that you don't.  The question is why you would want to do
it.  It seems like a strange precondition.  Static priorities are generally
chosen to satisfy schedulability requirements, and then ceiling priorities are
chosen to be the maximum of all the tasks that use the protected object.  By
specifying that the priority must be a particular value, you are effectively
requiring that exactly one task be allowed to call the operation (since in many
cases each task gets a unique priority).

I suppose you are simply pointing out that you can't use Get_Priority in the
Ravenscar subset, and you think there might be times when you would want to use
it.  This seems to have nothing to do with using it in a precondition of a
protected operation.

My own take is that there are a lot of features missing from the Ravenscar
subset (e.g. interesting entry barriers), and many of those features seem much
more valuable than Get_Priority.  But the point is that Ravenscar was designed
for simplicity, and you have to provide a strong argument for including
something in Ravenscar.  If in doubt, they left it out...

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

From: Randy Brukardt
Sent: Monday, November  5, 2012  6:36 PM

> I think the answer is that you don't.

I agree with Tucker here. There are a lot of things you might want to do in
Ravenscar that you can't (queuing on a protected entry with a non-trivial
barrier, for instance), and I think that is by design. I don't see any reason to
grumble about the intentional restrictions of Ravenscar -- if it is a real
problem, don't use Ravenscar.

It wouldn't hurt to hear from some real-time folks to confirm or reject this
opinion, but in the absence of that I don't see the need to do anything.

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

From: Brad Moore
Sent: Tuesday, November  6, 2012  9:25 AM

> I suppose you are simply pointing out that you can't use Get_Priority
> in the Ravenscar subset, and you think there might be times when you
> would want to use it.  This seems to have nothing to do with using it
> in a precondition of a protected operation.

Yes, I think more generally, there could be times when this could be useful. If
not in a precondition for a protected operation, then in a precondition for a
normal subprogram for example. One might want a guarantee that a certain
facility is only being used in real time tasks within a certain range of
priorities.

> My own take is that there are a lot of features missing from the
> Ravenscar subset (e.g. interesting entry barriers), and many of those
> features seem much more valuable than Get_Priority.

I suspect that interesting entry barriers were left out because it somehow
simplifies analysis, and predictability, or real time behaviour.

I doubt however that calling Get_Priority could have any effect on either
analysis, simplicity, or behaviour.

> But the point is that Ravenscar was designed
> for simplicity, and you have to provide a strong argument for
> including something in Ravenscar.  If in doubt, they left it out...

I'm guessing it was left out because it was easy to implement the restriction,
No_Dynamic_Priorities by using the general facility to disallow semantic
dependence on a package, Ada.Dynamic_Priorities in this case. Disallowing the
use of a particular subprogram would have been trickier, I would think.

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

From: Brad Moore
Sent: Tuesday, November  6, 2012  9:34 AM

...
> It wouldn't hurt to hear from some real-time folks to confirm or
> reject this opinion, but in the absence of that I don't see the need to do
> anything.

I think a stronger justification could eventually be provided, as the suggestion
is related to a joint paper being worked on for the next IRTAW. The ideas are
still being developed however, and would prefer to wait until the ideas have
been fully developed and vetted at IRTAW, rather than go into too much detail
right now.

Having Get_Priority in Ravenscar is not critical to the ideas, but it does seem
to be useful.

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

From: Randy Brukardt
Sent: Tuesday, November  6, 2012  12:29 PM

...
> > It wouldn't hurt to hear from some real-time folks to confirm or
> > reject this opinion, but in the absence of that I don't see the need
> > to do anything.
>
> I think a stronger justification could eventually be provided, as the
> suggestion is related to a joint paper being worked on for the next
> IRTAW. The ideas are still being developed however, and would prefer
> to wait until the ideas have been fully developed and vetted at IRTAW,
> rather than go into too much detail right now.

So you're saying you would like to pass this topic to IRTAW? I think that's an
excellent choice, as then I don't have to make an AI for it and we (the ARG)
don't have to talk about it. Please confirm that is what you meant.

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

From: Bob Duff
Sent: Tuesday, November  6, 2012  3:59 PM

> I suspect that interesting entry barriers were left out because it
> somehow simplifies analysis, and predictability, or real time behaviour.

That may have been part of it, but if those were the only reasons, then
Ravenscar wouldn't really need to be standardized.  You can always leave out
whatever features you like, if you think it simplifies analysis and so on for
you.

I think the main reason for leaving things out was to simplify the run-time
system.  The idea was that different vendors would supply cut-down run-time
systems that only support a small subset of Ada. With that in mind, it is
valuable to standardize that subset.

I don't think allowing Get_Priority in Ravenscar would cause an earthquake, but
I'll just repeat my usual hesitance to make changes to the language without
strong reasons, and without first letting the dust settle w.r.t. Ada 2012.

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

From: Brad Moore
Sent: Wednesday, November  7, 2012  8:54 AM

> So you're saying you would like to pass this topic to IRTAW? I think
> that's an excellent choice, as then I don't have to make an AI for it
> and we (the
> ARG) don't have to talk about it. Please confirm that is what you meant.

Yes, I think it makes sense to pass this through IRTAW, and see where it goes.

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

Questions? Ask the ACAA Technical Agent