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

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

!standard 5.5.2(2/3)          15-06-04 AI05-0164-1/00
!standard 5.5.2(5/4)
!standard 5.5.2(7/3)
!class Amendment 15-06-04
!status work item 15-06-04
!status received 15-04-24
!priority Low
!difficulty Easy
!subject Max Queue Length aspect for protected entries
!summary
* TBD
!problem
In order to facilitate timing analysis, a new representation aspect Max_Queue_Length is needed.
!proposal
Max_Queue_Length for a protected entry declaration 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.
!wording
** TBD.
!discussion
It has been suggested that such a queue length should be global to a protected type, not an individual entry. Since implementations are allowed (and encouraged) to use a single queue for each object (all entries of a PO are serviced together), having different lengths for the queue would just complicate (rather than simplify) the implementation. One would hope that a super-Ravenscar would still allow simplifying the runtime.
If a limit for an individual entry is needed, that seems more appropriate for a precondition or assertion.
!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).

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


Questions? Ask the ACAA Technical Agent