Version 1.5 of ai12s/ai12-0164-1.txt

Unformatted version of ai12s/ai12-0164-1.txt version 1.5
Other versions for file ai12s/ai12-0164-1.txt

!standard D.4(16)          15-10-17 AI12-0164-1/03
!class Amendment 15-06-04
!status work item 15-06-04
!status received 15-04-24
!priority Low
!difficulty Easy
!subject Max_Entry_Queue_Length aspect for entries
!summary
Aspect Max_Entry_Queue_Length is introduced.
!problem
In order to facilitate timing analysis, a new representation aspect Max_Entry_Queue_Length is needed. This should be applicable to a specific entry or a type (task or protected).
!proposal
Max_Entry_Queue_Length for a entry declaration specifies the maximum number of callers allowed on that entry. Violation of this restriction results in the raising of Program_Error at the point of the call or requeue. The value specified for the Max_Entry_Queue_Length aspect for an entry is no higher than any specified for the corresponding type, and both are no higher than the Max_Entry_Queue_Length partition-wide restriction.
!wording
[Editor's note: I believe this is intended to be an Annex D capability, so I put it there. I put it under D.4 as that's the closest match for it, but perhaps it should have its own clause somewhere??]
Add after D.4(16):
Static Semantics
For a task type (including the anonymous type of a single_task_declaration) or protected type (including the anonymous type of a single_protected_declaration), the following language-defined representation aspect may be specified:
Max_Entry_Queue_Length
The type of aspect Max_Entry_Queue_Length is Integer.
If directly specified, the aspect_definition shall be a static expression. If not specified, the aspect has value -1 (representing an unspecified queue length).
For an entry_declaration, the following language-defined representation aspect may be specified:
The type of aspect Max_Entry_Queue_Length is Integer.
If directly specified, the aspect_definition shall be a static expression. If not specified, the aspect has value -1 (representing an unspecified queue length).
Legality Rules
If aspect Max_Entry_Queue_Length for a type has a nonconfirming value, aspect Max_Entry_Queue_Length for an individual entry of that type shall be less than or equal to the value of the aspect for the type.
AARM Ramification: Aspect Max_Entry_Queue_Length can specify less than the partition-wide or type-wide default, but it can't expand the length of a queue.
Post-Compilation Rules
If a restriction Max_Entry_Queue_Length applies to the partition, a nonconfirming value of an aspect Max_Entry_Queue_Length (for a type or individual entry) shall be less than or equal to the value of the restriction.
AARM Ramification: 13.12(6) says that the restriction value has to be static, so this is statically checkable. But the restriction does not have to be in the same compilation as the aspect, so the check cannot, in general, be done until link time.
Dynamic Semantics
If a nonconfirming value is specified for Max_Entry_Queue_Length for a type, and an entry call or requeue would cause the queue for any entry of a type to become longer than the specified value, then Program_Error is raised at the point of the call or requeue.
[Editor's note: I tried to borrow the wording of D.7(19.1/2), but it is worded in terms of "violation of this restriction", which doesn't work for an aspect. I'm not excited about "would cause", but I can't find better wording. And this isn't my AI anyway, I'm just trying to help out Alan. :-)]
If a nonconfirming value is specified for Max_Entry_Queue_Length for an entry, and an entry call or requeue would cause the queue for an entry to become longer than the specified value, then Program_Error is raised at the point of the call or requeue.
!discussion
We originally considered just having this aspect apply to protected entries, but there seems to be no reason to make such a limitation.
Aspects should only be able to tighten any more global restriction. It would be a problem for analysis if the entire source code of the program had to be inspected to see if there is any extension of the global restriction. We note that the name of the restriction is also Max_Entry_Queue_Length which implies that it is the maximum length; it's not named Default_Entry_Queue_Length.
It did not seem useful to have an attribute that can be used to query the aspect; use of such an attribute could lead to race conditions.
!ASIS
?? How are aspects handled??
!ACATS test
An ACATS C-Test is needed to check that the new capabilities are supported.
!appendix

From: Brad Moore
Sent: Friday, April 24, 2015  2:19 AM

Here is the second issue that I was to bring forward to the ARG.
Thanks to Jose Ruiz for passing on the initial writeup for both of these issues.
I am mostly just relaying his text.

"In order to facilitate timing analysis, the group supported the addition of a
new representation aspect (Max_Queue_Length) for protected entry declarations
that specifies the maximum number of callers allowed on that entry. Violation of
this restriction results in the raising of Program_Error at the point of the
call or requeue. A check is made that the expression specified in the
Max_Queue_Length aspect lower or equal than the Max_Entry_Queue_Length
partition-wide restriction. If the check fails, Program_Error is raised."

Both of these issues (this and determinism for FIFO_Queueing [AI12-0163-1 -
Editor]) came up during discussions around proposals to explore the creation of
other real-time restriction profiles that were not as restrictive as Ravenscar.

In Ravenscar, we have Max_Entry_Queue_Length => 1, which applies to all
protected objects. The Ravenscar restrictions are useful for those real-time
environments that need the full set of restrictions, but in softer real-time
environments that do not need all the restrictions, the loss of expressability
can be annoying or awkward to work around. Having one restriction,
Max_Entry_Queue_Length that applies to all PO's is too limiting, as some PO's
might well be well suited for a queue length of 1, but others might need
different sized queues. For example, a PO for multiple producers for a single
consumer might need a queue length that reflects the number of producers.

I think this proposal would facilitate timing analysis because only the PO's
with longer queues would need more complex analysis, whereas shorter queues (eg
queue length 1) would allow for simpler analysis on other parts of the system.
There may be other ways that this would facilitate timing analysis as well. In
particular, all the queues do need to be bounded to allow for the real-time
analysis. Jose's writeup above suggests an aspect that can be applied uniquely
for each entry in a PO, but I am thinking it might be desirable to apply the
aspect globally to all entry declarations in a protected type. I am thinking
here of AI12-0129, where we decided that the Exclusive_Functions aspect should
similarly be applied to the protected type as a whole, rather than uniquely for
each protected function.

As for the first issue, I believe it was mentioned that for such a real-time
environment that was being discussed, FIFO_Queueing might be the desired
queueing policy which allows for simpler analysis, but determinism would also be
needed to facilitate the analysis.

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

From: Jean-Pierre Rosen
Sent: Friday, April 24, 2015  2:31 AM

> Having one restriction, Max_Entry_Queue_Length that applies to all
> PO's is too limiting, as some PO's might well be well suited for a
> queue length of 1, but others might need different sized queues. For
> example, a PO for multiple producers for a single consumer might need
> a queue length that reflects the number of producers.

But in this case, you would have a queue length for the consumer >1, with
Max_Entry_Queue_Length =1, and this looks like a common situation => it has to
be allowed.

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

From: Bob Duff
Sent: Friday, April 24, 2015  8:37 AM

> I think this proposal would facilitate timing analysis because only
> the PO's with longer queues would need more complex analysis, whereas
> shorter queues (eg queue length 1)

Queue length 1 might indeed facilitate analysis.  But do we really need a new
language feature to check it at run time?  Why not do some more analysis to
prove that max queue length = 1, and comment the code? I mean, why is this
particular property more important than any other global property?

Again, where is the user demand for such a feature?  If there is, then users can
request implementation of it, and if it turns out to be useful, THEN we can
think about standardizing it.

> would allow for simpler analysis on other parts of the system. There
> may be other ways that this would facilitate timing analysis as well.
> In particular, all the queues do need to be bounded to allow for the real-time
> analysis.

By the way, there's always a worst-case bound on queue length: the number of
tasks (which in many real-time systems is a statically-known number).

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

From: Alan Burns
Sent: Monday, September 14, 2015  5:01 AM

I had some edits to do on AI-0164 (Max Queue Length for entries). I enclose an
updated AI [this is version /01 of the AI] - BUT I have not done the !wording
- I am not sufficiently familiar with aspects to get this right, so rather
than get it wrong can I leave it to the meeting to actually do this - I am
sure it is straightforward if you know what you are doing!!

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


Questions? Ask the ACAA Technical Agent