!standard D.02.02 (05) 04-09-27 AI95-00333/05 !standard D.02.02 (03) !class binding interpretation 03-07-25 !status Amendment 200Y 04-09-27 !status ARG Approved 8-0-1 04-09-18 !status work item 03-07-25 !status received 03-02-34 !qualifier Clarification !priority Low !difficulty Easy !subject Other Locking_Policies can be used with FIFO_Within_Priorities !summary Other Locking_Policies can be used with FIFO_Within_Priorities. !question Why does D.2.2(5) require that Ceiling_Locking be used whenever FIFO_Within_Priorities is used? If an implementation supports another locking policy, why shouldn't it be allowed to combine that policy with FIFO_Within_Priorities? !recommendation (See Wording.) !wording Delete D.2.2(5). Add after D.2.2(13): Implementation Requirements An implementation shall allow specifying both the task dispatching policy as FIFO_Within_Priorities and the locking policy (see D.3) as Ceiling_Locking for a single partition. Similar changes apply to Non-Premptive dispatching (AI-298) and Round-robin (AI-355). !discussion There is no identified reason for this restriction. While analysis of a real-time program requires the use of well-defined locking and dispatching policies, such an application should already be specifying the policies that they are assuming. Moreover, if an implementation provides its own well-defined policy, why shouldn't it be allowed to combine that policy with FIFO_Within_Priorities? There is no value in forcing an implementation to support a second name for the same dispatching policy just to be able to use a different locking policy. Finally, an implementation's default policy should be selected by its user's requirements (such as performance or compatibility with a target OS), not by the standard. The predefined policies may not be the best on a given target, and forcing users to specify some implementation-defined policy to get the best performance is just overspecification (and also makes code less portable). However, there is a benefit to insuring that Ceiling_Locking can be used with FIFO_Within_Priorities, so that carefully designed systems can be ported to new targets. Such insurance can cleanly be accomplished with an Implementation Requirement. Thus, we've adopted the Implementation Requirement given above to replace D.2.2(5). !corrigendum D.2.2(04) !comment This is a fake to trigger conflict processing with AI-355. The real !comment change is in conflict text. @drepl A Task_Dispatching_Policy pragma is a configuration pragma. @dby A Task_Dispatching_Policy pragma is a configuration pragma. !corrigendum D.2.2(05) @ddel If the FIFO_Within_Priorites policy is specified for a partition, then the Ceiling_Locking policy shall also be specified for the partition. !corrigendum D.2.2(13) @dinsa In addition, when a task is preempted, it is added at the head of the ready queue for its active priority. @dinst @i<@s8> An implementation shall allow specifying both the task dispatching policy as FIFO_Within_Priorities and the locking policy (see D.3) as Ceiling_Locking for a single partition. !corrigendum D.2.4(01) !comment This is a fake to trigger conflict processing with AI-298. The real !comment change is in conflict text. @dinsc @i<@s8> An implementation shall allow specifying both the task dispatching policy as Non_Preemtive_FIFO_Within_Priorities and the locking policy (see D.3) as Ceiling_Locking for a single partition. !corrigendum D.2.5(01) !comment This is a fake to trigger conflict processing with AI-355. The real !comment change is in conflict text. @dinsc @i<@s8> An implementation shall allow specifying both the task dispatching policy as Round_Robin_Within_Priorities and the locking policy (see D.3) as Ceiling_Locking for a single partition. !ACATS test There is no test for the deleted rule (D.2.2(5)). ACATS tests CXD2001.A (and 7 others) test (as a side-effect) that specifying both is allowed. No further tests are needed. !appendix This is a question from Robert Dewar. Note that Robert is not currently on the ada-comment list, but I'll forward any replies to him. !topic Why does FIFO_Within_Priorities require the Ceiling_Locking policy? !reference RM95 D.2.2(5) !from Robert Dewar 02-24-03 This concerns the rule in D.2.2: 5 If the FIFO_Within_Priorities policy is specified for a partition, then the Ceiling_Locking policy (see D.3) shall also be specified for the partition. We have never enforced this rule, and it seems silly to do so, since I can't tell why it is there. What possible value is it to make it impossible to mix different task dispatching policies and queuing policies. It makes no sense at all, and the AARM gives no hint for the motivation behind this rule. In standard Ada, these are the only possible values to be specified. If one specifies FWP, and default ceiling locking, then there are two possibilities: 1. For some reason, the implementation only works out nicely if the default queuing policy in this case is Ceiling_Locking, fine do it! 2. The default locking policy is something else which works fine with FWP. So why on earth make this illegal. In an implementation that introduces additional policies, it makes absolutely ZERO sense to constrain the implementation in this manner. I am very reluctant to implement this silly rule, without first asking the ARG why it is there, and suggesting it be got rid of. **************************************************************** From: Randy Brukardt Sent: Wednesday, July 28, 2004 10:10 PM At the Palma meeting, we straw voted on this AI (I've left out the choices that were disliked by many): 2) Fifo implies ceiling locking is default: 8-0. 3) Fifo means that some policy must be specified: 6-1. 4) Add an Implementation Requirement that the combination must be supported and delete D.2.2(5): 6-0. ... Narrowing the choices to the three most popular, we take a preference poll. Prefer (2): 6; Prefer (3): 1; Prefer (4): 2. The AI should be rewritten to reflect resolution (2). --- I'm trying to implement this resolution. I came up with the following replacement for D.2.2(5): If the FIFO_Within_Priorities policy is specified for a partition, and no Locking_Policy (see D.3) is specified for the partition, then the Locking_Policy is Ceiling_Locking. But I don't much like this, because it seems to be an implementation problem. If the implementation has any compile-time effects of the locking policy, it may not know what the policy is until very late during the compilation of the partition. It could use 10.1.5(9) to restrict Task_Dispatching_Policy *and* Locking_Policy to the beginning of the environment, but that would be unfriendly and incompatible if it currently is not required. I also don't like the "magic" nature of this. We're replacing a requirement that something be specified a certain way to saying that you don't have to specify it at all. That doesn't seem very Ada-like; it would make more sense to require you to say what you mean. I missed the discussion on this AI (when I arrived, the above list was on the board, and we immediately took the straw vote then moved on), so I don't know what the issues discussed were (if any). So that makes it hard to reason about this. I particularly don't understand where "default" comes from here, because Ada doesn't currently say or require anything (other than Chapter 9) about the default policies, and it seems like a big step backwards to start making such requirements. And there is no compatibility problem to worry about: the current rule requires both to be specified; what happens if one isn't specified doesn't matter because it can't happen. Indeed, this change is more likely to introduce a performance compatibility problem by forcing implementations to make Ceiling_Locking the default Locking_Policy, which would add overhead in a simple implementation. I'd much prefer if D.2.2(5) was replaced by: If the FIFO_Within_Priorities policy is specified for a partition, then a Locking_Policy (see D.3) also shall be specified for the partition. which is cleaner and has no magic semantics. However, that is option (3) and that got less support at the meeting. Comments?? **************************************************************** From: Alan Burns Sent: Friday, July 30, 2004 3:07 AM Yes option 2 was a compromise. Wishing to keep the close association between FIFO and Ceiling Locking but not always requiring both. I agree that using a default does not fit well with Ada style, but the second suggestion you have was not supported by the straw votes. Does not seem to be a solution to this; but here is another possibility: If the FIFO_Within_Priorities policy is specified for a partition, then the Locking_Policy (see D.3) is Ceiling_Locking unless a different Locking_Policy is defined for the partition. not sure this is any better! **************************************************************** From: Tucker Taft Sent: Friday, July 30, 2004 4:47 AM Rather than "... unless a different Locking_Policy is defined..." perhaps something like "unless overridden by the explicit specification of some other Locking_Policy". I don't understand Randy's concern about knowing the locking policy in advance, since that is an existing problem. If you must know the locking policy when generating code, then the implementation can require that it be specified prior to compiling any code in the environment, per 10.1.5(9). In any case, all implementations have a default locking policy. I don't see how we could possibly be sacrificing safety by specifying what this default is under certain circumstances. Users can still specify Ceiling_Locking explicitly. But now, if they *don't* specify the Locking_Policy but they do specify the dispatching policy, they get additional implementation uniformity. That seems consistent with other attempts to achieve uniformity in the real-time annex. And my suspicion is that almost all implementations have Ceiling_Locking as the default, and almost no implementations currently enforce D.2.2(5). **************************************************************** From: Tullio Vardanega Sent: Friday, July 30, 2004 11:06 AM I missed that part of the Palma meeting. If I were present I would have voted for option 3), which did not fly :-( To me, Alan's text as modified by Tucker has a better taste than Randy's initial cut at it, because it does not reason on the absence of, but on the presence of possibly overring locking_policy configuration. **************************************************************** From: Randy Brukardt Sent: Friday, July 30, 2004 7:02 PM The rule proposed is: If the FIFO_Within_Priorities policy is specified for a partition, then the Locking_Policy (see D.3) is Ceiling_Locking unless overridden by the explicit specification of some other Locking_Policy. This doesn't seem like a "post-compilation rule"; indeed, it's not a "rule" at all, as it doesn't make anything illegal. I think it belongs under "static semantics", is that right? --- Tucker wrote: > In any case, all implementations have a default locking policy. > I don't see how we could possibly be sacrificing safety by > specifying what this default is under certain circumstances. It's not safety that's being sacrificed, it's performance. The default locking policy means "don't care what the policy is, just make it fast and meet Chapter 9". This is not something that you can name, of course, because if you do, you are overconstraining the implementation on a different target. That is, on a bare target, Ceiling_Locking might very well be efficient, but on a hosted operating system, something else is likely to be more efficient (because Ceiling_Locking implies repeating checks that the OS probably will make). Now, of course if you need analyzability in the face of priority changes and the like, then you need to specify the dispatching and locking policy. But if you only care that pre-emptive dispatching is used, you may only care about the dispatching policy. In that case, you're just paying extra for rules that you don't need. This is a serious issue given the addition of several new language-defined dispatching policies. If you need EDF or non-preemptive, you'll certainly have to specify that; but dragging in the cost of ceiling locking (which you may or may not need) on top of that is silly. (Unless, of course, the assumption is that the real-time annex cannot be implemented on top of general purpose OSes like Windows and Linux -- but that would be contentious as well.) Compatibility is needed, of course, but any rule suggested preserves that, as long as there is a requirement that Ceiling_Locking can be used with these policies. > Users can still specify Ceiling_Locking > explicitly. But now, if they *don't* specify the Locking_Policy > but they do specify the dispatching policy, they get > additional implementation uniformity. That seems consistent > with other attempts to achieve uniformity in the real-time annex. This seems worse to me than the current rule. It means that to get maximum performance, you have to specify a bunch of implementation-defined policies; that's precisely what we're trying to get away from here (the need for implementations to define a number of policies that are *almost the same as* some language-defined ones). And any hope of portability has gone out the window. In general, I think the real-time annex goes way too far in trying "to achieve uniformity". It males it impractical to implement on top of a general purpose OS, for instance. (We as a group have decided to ignore these issues and let implementations claim Annex D support on Windows, etc., but those implementations don't really meet the rules. Not being comfortable with that, I've never seriously considered any Annex D support in Janus/Ada.) > And my suspicion is that almost all implementations have > Ceiling_Locking as the default, and almost no implementations > currently enforce D.2.2(5). That seems obvious given the lousy tasking performance of other implementations on Windows! :-) I've had customers beg us not to replace our tasking with a threaded implementation for this reason -- which is seems bad for Ada (competitors with lots more money ought to be able to do better than our "we just want it to work as Chapter 9 says" supervisor). But I suppose my opinion doesn't count for much in this arena, given it is not an area where we have much experience. I suppose I'll just have to vote against my own AI... **************************************************************** From: Robert I. Eachus Sent: Saturday, July 31, 2004 12:41 AM I strongly agree with Randy here. If the intent is that Annex D conformant implementations must support the combination of FIFO_Within_Priorities and Ceiling_Locking, then say that, and only that. Messing with the default policies will create uniformly poor performance. Saying nothing should mean "Give me the best you have." If that is Ceiling_Locking fine. If it is whatever the OS provides, that should be fine too. **************************************************************** From: Robert Dewar Sent: Saturday, July 31, 2004 8:20 AM We find that the vast majority of our customers require that Ada tasking by default map to the operating system handling of tasks. That's because they use foreign code, can't tolerate blocking on system calls, and generally want to interact with the OS at an appropriate level. This is true even of hard real time applications. So it's not just a matter of poor performance, but basically unacceptable semantics. So the default behavior should definitely NOT be legislated. Furthermore, to get the Annex D pragma type behavior requires root access on many machines, so it is definitely specialized :-) **************************************************************** From: Tucker Taft Sent: Sunday, August 1, 2004 9:27 PM Note that we are *not* specifying the default behavior overall. Currently, the somewhat odd rule is that *if* you specify FIFO_Within_Priorities, then you *must* specify Ceiling_Locking. No ifs, ands, or buts. We want to relax that and allow different locking policies with FIFO_Within_Priorities. We considered various ways to accomplish this. We generally agreed to say that *if* you specify FIFO_Within_Priorities, then you also get Ceiling_Locking, unless you *override* that with some other. If you *don't* specify FIFO_Within_Priorities, then you get whatever is the implementation default dispatching and locking policies. Randy suggests the alternative that *if* you specify FIFO_Within_Priorities, then you must also specify *some* locking policy. That seems a bit odd as well. In any case, we want to create more flexibility in terms of combinations of dispatching policies and locking policies, while ensuring that the FIFO_Within_Priorities/Ceiling_Locking combo is still supported. **************************************************************** From: John Barnes Sent: Monday, August 2, 2004 1:55 AM So why don't we simply say that you can specify FIFO_Within_Piriorities and Ceiling _Locking independently. And that there are other policies which can be used in certain combinations as well - including with one of those. And some combinations might not work but FIFO_Within_Priorities and Ceiling_Locking always work together. **************************************************************** From: Robert I. Eachus Sent: Tuesday, August 3, 2004 1:13 AM Tucker Taft said: > Note that we are *not* specifying the default behavior overall. > Currently, the somewhat odd rule is that *if* you > specify FIFO_Within_Priorities, then you *must* specify > Ceiling_Locking. Yes, this rule is odd, but it doesn't really say anything meaningful other than what we are trying to specify now. To conform to Annex D, you must support FIFO_Within_Priorities and Ceiling_Locking, and the combination must be allowed. The RM doesn't not, and cannot say anything about what happens when you specify, FIFO_Within_Priorities_Wink_Wink_Nudge_Nudge and Some_Alternative_to_Ceiling_Locking. Or even what happens when you specify FIFO_Within_Priorities in a non-standard mode. To achieve more standardization, we should say no more than that to conform to Annex D an implementation must support FIFO_Within_Priorities and Ceiling_Locking, and it must be possible to choose both together. For example, if we decide that Ceiling_Locking must be the default with FIFO_Within_Priorities, then my definition of standard mode can require Ceiling_Locking to be set by a command line parameter, just like GNAT currently requires -gnato for standard mode. The goal should be to avoid the necessity for such kludges, not require implementors to invent new ones. The reality is that there will be some people who use standard mode and want FIFO_Within_Priorities and Ceiling_Locking, and there will be users who want some (any?) reasonable scheduling behavior on the target hardware. **************************************************************** From: Robert Dewar Sent: Tuesday, August 3, 2004 5:28 AM Tucker Taft wrote: > Note that we are *not* specifying the default behavior overall. > Currently, the somewhat odd rule is that *if* you > specify FIFO_Within_Priorities, then you *must* specify > Ceiling_Locking. No ifs, ands, or buts. That seems fine to me, I prefer this original "somewhat odd rule" to any of the alternatives so far offered, and think that this is not sufficiently broken to require a fix. **************************************************************** From: Robert Dewar Sent: Tuesday, August 3, 2004 5:31 AM rieachus@comcast.net wrote: > To achieve more standardization, we should say no more than that to > conform to Annex D an implementation must support FIFO_Within_Priorities > and Ceiling_Locking, and it must be possible to choose both together. OK, sorry, now I understand the issue better, and I agree with the above entirely, that is *all* that should be said. It should of course be possible to specify any combination of policies that an implementation supports, and if one policy is specified and not the other, then the unspecified one should be impl dependent. **************************************************************** From: Pascal Leroy Sent: Monday, August 9, 2004 7:15 AM > So why don't we simply say that you can specify > FIFO_Within_Piriorities and Ceiling _Locking independently. > And that there are other policies which can be used in > certain combinations as well - including with one of those. > And some combinations might not work but > FIFO_Within_Priorities and Ceiling_Locking always work together. This was in fact one of the options we discussed in Palma (and the one I personally favored) but for some reason the group went down the path of insanity. I believe we should reconsider this decision, since it's becoming apparent that putting constraints on the default policy is just going to cause trouble. **************************************************************** From: Randy Brukardt Sent: Friday, August 27, 2004 8:06 PM Based on this, and based on the fact that option (4) didn't have any opposition in Palma (it just came in second in the beauty contest), I've rewritten the AI using that option. This will allow me to vote for my own AI (which is preferable :-). Note that we'll also make similar changes to all of the new dispatching policies defined by the "Alan AIs". That's an integration issue. ****************************************************************