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

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

!standard D.4(16)          16-11-14 AI12-0164-1/04
!class Amendment 15-06-04
!status Amendment 1-2012 16-11-14
!status ARG Approved 8-0-1 16-10-09
!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 an 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
Add after D.4(16):
Static Semantics
For an entry_declaration, 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 no less than -1. If not specified, the aspect has value -1 (representing no additional restriction on queue length).
Legality Rules
If the Max_Entry_Queue_Length aspect for a type has a nonnegative value, the Max_Entry_Queue_Length aspect for every individual entry of that type shall not be greater than the value of the aspect for the type. The Max_Entry_Queue_Length aspect of a type is nonoverridable.
[Editor's note -- the term "nonoverridable" must be generalized to allow for its usage with a numeric-valued aspect; AI12-0206-1 does this.]
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 a partition, any value specified for the Max_Entry_Queue_Length aspect specified for the declaration of a type or entry in the partition shall not be greater than 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.
These aspects would be very useful for restricted tasking profiles more general than Ravenscar. IRTAW has at least one such proposal for a new profile.
!corrigendum D.4(16)
Insert after the paragraph:
The implementation should use names that end with “_Queuing” for implementation-defined queuing policies.
the new paragraphs:
Static Semantics
For a task type (including the anonymous type of a single_task_declaration), protected type (including the anonymous type of a single_protected_declaration), or an entry_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 no less than -1. If not specified, the aspect has value -1 (representing no additional restriction on queue length).
Legality Rules
If the Max_Entry_Queue_Length aspect for a type has a nonnegative value, the Max_Entry_Queue_Length aspect for every individual entry of that type shall not be greater than the value of the aspect for the type. The Max_Entry_Queue_Length aspect of a type is nonoverridable.
Post-Compilation Rules
If a restriction Max_Entry_Queue_Length applies to a partition, any value specified for the Max_Entry_Queue_Length aspect specified for the declaration of a type or entry in the partition shall not be greater than the value of the restriction.
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 the type to become longer than the specified value, then Program_Error is raised at the point of the call or requeue.
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.
!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!!

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

From: Steve Michell
Sent: Saturday, June 11, 2016  9:33 AM

My notes from IRTAW 2016 are appended.

IRTAW 2016 discussed this item (April 2016) in the context of extensions to
Ravenscar. The workshop was of the opinion that the only setting needed for
entry size restrictions for Ravenscar is the one provided by pragma
Restrictions(Max_Entry_Queue_Length=1). There was a proposal to the workshop
to extend Ravenscar to permit more than a single entry in a protected
type/object and to permit queue lengths longer than one, and settable
Protected type by protected type. 

Pat Rogers indicated that AdaCore would be creating a profile (nominally
Extended-Ravenscar)  that  had those properties, but the workshop refused to
agree to extending basic Ravenscar in this way. The workshop also stated its
preference that the new profile not be called Ravenscar-something. It should
be noted that pragma restrictions(Max_Entry_Queue_Length=N) is a library-level
item that affects all entries in a program, so being able to apply this
restriction on a type-by-type is important.  

For a new profile that limits entry queue lengths, either by task type or by
protected type, this aspect would be very useful, and since AdaCore is
finishing the implementation of extended-Ravenscar, may be essential.

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


Questions? Ask the ACAA Technical Agent