!standard D.02.02 (05) 03-07-25 AI95-00333/01 !class binding interpretation 03-07-25 !status work item 03-07-25 !status received 03-02-34 !qualifier Clarification !priority Low !difficulty Easy !subject FIFO_Within_Priorities does not require the Ceiling_Locking policy !summary There is no requirement to use Ceiling_Locking when using 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). !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, if an implementation needs Ceiling_Locking in order for FIFO_Within_Priorities to work properly, it can define the default locking policy to be Ceiling_Locking. Again, there is no value to the restriction. Thus, we've removed this restriction. !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. !ACATS test Since this gives more permission, no test is needed. There is no test for the rule that was deleted. !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. ****************************************************************