Version 1.5 of ais/ai-00333.txt

Unformatted version of ais/ai-00333.txt version 1.5
Other versions for file ais/ai-00333.txt

!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
!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
Add after D.2.2(3):
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.
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.
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)
Insert after the paragraph:
The policy_identifier shall either be FIFO_Within_Priorities or an implementation-defined identifier.
the new paragraph:
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)
Delete the paragraph:
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
It would be hard to test if the policy is indeed Ceiling_Locking. 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.

****************************************************************

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...

****************************************************************


Questions? Ask the ACAA Technical Agent