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