CVS difference for ais/ai-00333.txt

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

--- ais/ai-00333.txt	2004/07/31 04:28:12	1.5
+++ ais/ai-00333.txt	2004/09/04 01:13:45	1.6
@@ -1,4 +1,4 @@
-!standard D.02.02      (05)                            04-07-30  AI95-00333/03
+!standard D.02.02      (05)                            04-08-27  AI95-00333/04
 !standard D.02.02      (03)
 !class binding interpretation 03-07-25
 !status work item 03-07-25
@@ -26,15 +26,15 @@
 
 !wording
 
-Add after D.2.2(3):
+Delete D.2.2(5).
 
-Static Semantics
+Add after D.2.2(13):
 
-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.
+Implementation Requirements
 
-Delete D.2.2(5):
+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.
 
 !discussion
 
@@ -50,27 +50,17 @@
 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 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.
-
+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(05)
 
@@ -78,10 +68,24 @@
 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<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.
+
+
 !ACATS test
 
-It would be hard to test if the policy is indeed Ceiling_Locking.
-There is no test for the rule that was deleted.
+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
 
@@ -323,6 +327,169 @@
 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.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent