CVS difference for ais/ai-00333.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00333.txt

--- ais/ai-00333.txt	2003/07/26 03:26:03	1.2
+++ ais/ai-00333.txt	2004/07/29 06:42:19	1.3
@@ -1,16 +1,15 @@
-!standard D.02.02      (05)                            03-07-25  AI95-00333/01
+!standard D.02.02      (05)                            04-07-28  AI95-00333/02
 !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
+!subject Other Locking_Policies can be used with FIFO_Within_Priorities
 
 !summary
 
-There is no requirement to use Ceiling_Locking when using
-FIFO_Within_Priorities.
+Other Locking_Policies can be used with FIFO_Within_Priorities.
 
 !question
 
@@ -26,8 +25,11 @@
 
 !wording
 
-Delete D.2.2(5).
+Replace D.2.2(5) 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.
+
 !discussion
 
 There is no identified reason for this restriction.
@@ -37,22 +39,23 @@
 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.
+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.
+Thus, we've replaced this restriction by a requirement that some locking
+policy is specified for a partition with the FIFO_Within_Priorities dispatching
+policy.
 
 !corrigendum D.2.2(05)
 
-@ddel
+@drepl
 If the FIFO_Within_Priorites policy is specified for a partition, then the
 Ceiling_Locking policy shall also be specified for the partition.
+@dby
+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.
 
 !ACATS test
 
@@ -94,6 +97,68 @@
 
 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??
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent