CVS difference for ais/ai-00333.txt

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

--- ais/ai-00333.txt	2004/07/31 00:00:50	1.4
+++ ais/ai-00333.txt	2004/07/31 04:28:12	1.5
@@ -1,4 +1,5 @@
-!standard D.02.02      (05)                            04-07-28  AI95-00333/02
+!standard D.02.02      (05)                            04-07-30  AI95-00333/03
+!standard D.02.02      (03)
 !class binding interpretation 03-07-25
 !status work item 03-07-25
 !status received 03-02-34
@@ -25,10 +26,15 @@
 
 !wording
 
-Replace D.2.2(5) by:
+Add after D.2.2(3):
 
+Static Semantics
+
 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.
+the Locking_Policy (see D.3) is Ceiling_Locking unless overridden by the
+explicit specification of some other Locking_Policy.
+
+Delete D.2.2(5):
 
 !discussion
 
@@ -44,23 +50,38 @@
 for the same dispatching policy just to be able to use a different locking
 policy.
 
-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.
+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 could cleanly be accomplished with an
+Implementation Requirement. Unfortunately, there still is support for
+explicitly requiring Ceiling_Locking (even if a default policy provides
+better performance on the target system and the programmer has no need for
+specifying anything other than the dispatching policy). Thus we've adopted the
+misguided rule given below.
+
+!corrigendum D.2.2(03)
+
+@dinsa
+The @i<policy>_@fa<identifier> shall either be FIFO_Within_Priorities or an
+implementation-defined @fa<identifier>.
+@dinst
+@i<@s8<Static Semantics>>
+
+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.
 
+
 !corrigendum D.2.2(05)
 
-@drepl
+@ddel
 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
 
-Since this gives more permission, no test is needed. There is no test for the
-rule that was deleted.
+It would be hard to test if the policy is indeed Ceiling_Locking.
+There is no test for the rule that was deleted.
 
 !appendix
 
@@ -217,6 +238,91 @@
 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...
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent