Version 1.7 of ais/ai-00394.txt

Unformatted version of ais/ai-00394.txt version 1.7
Other versions for file ais/ai-00394.txt

!standard D.07(09) 05-12-05 AI95-00394/06
!standard D.07(10)
!standard D.07(15)
!standard D.13.1(01)
!standard H.4(2)
!standard H.4(3)
!standard H.4(9)
!standard H.4(16)
!standard H.4(23)
!standard J.13(1)
!standard 13.12(7)
!class amendment 05-01-20
!status Amendment 200Y 05-02-25
!status ARG Approved 9-0-1 05-02-13
!status work item 05-01-20
!status received 05-01-20
!priority High
!difficulty Easy

!subject Redundant Restriction Identifiers and completing Ravenscar definition

!summary

This AI moves existing restriction identifiers to Annex J, and modifies the definition of the Ravenscar profile. It also completes the definition of the Ravenscar profile by including new restrictions that concern new features of the language.

!problem

The new restriction identifier, No_Dependence, has made existing identifiers redundant and allows the Ravenscar profile to be defined without the need to introduce further new identifiers. It also makes AI-353 redundant, and a number of new restriction identifiers in AI-305.

To complete the definition of Ravenscar it is necessary to restrict the use of the following new features:

1. CPU Timers 2. Group Timers 3. Specific handlers for task termination.

The first two are restricted due to their incompatibility with Ravenscar; the events they define identify dynamic actions that Ravenscar cannot easily utilize. The required restrictions are obtained by the use of restriction identifier No_Dependence.

As tasks in Ravenscar are not intended to terminate (and are all at the library level) it is deemed adequate for there to be only a fall-back handler. The run-time will be simpler if specific handlers are not supported. To define this restriction a new restrictions identifier is defined: No_Specific_Termination_Handlers.

To make it clear that if a Ravenscar task does terminate the fall-back handler (if there is one) will be executed, the definition of No_Task_Termination is modified.

Finally, it was noted that the phrase "restriction xxx apply in this Annex" doesn't make much sense. The wording was revised to eliminate this phrase.

!proposal

(See wording.)

!wording

Delete (the original) D.7(10), H.4(9), and H.4(16).

Delete No_Calendar and No_Task_Attributes_Package from the wording changes of AI-305.

AI-353 should be dropped from the Amendment.

Add new Section in Annex J:

J.13 Dependence Restriction Identifiers

The following restrictions involve dependence on specific language-defined units. The more general No_Dependence restriction should be used for this purpose.

Static Semantics

The following restriction_identifiers exist:

No_Asynchronous_Control

Semantic dependence on the predefined package Asynchronous_Task_Control is not allowed.

No_Unchecked_Conversion

Semantic dependence on the predefined generic function Unchecked_Conversion is not allowed.

No_Unchecked_Deallocation

Semantic dependence on the predefined generic procedure Unchecked_Deallocation is not allowed.

Delete H.4(2).

Change H.4(3) to read:

The following restriction_identifiers are language defined:

Add the following before H.4(24):

An implementation of this Annex shall support: o the restrictions defined in this subclause; and o the following restrictions defined in D.7: No_Task_Hierarchy,

No_Abort_Statement, No_Implicit_Heap_Allocation; and

o the pragma Profile(Ravenscar); and o the following uses of restriction_parameter_identifiers defined in D.7,

which are checked prior to program execution:

* Max_Task_Entries => 0,

* Max_Asynchronous_Select_Nesting => 0, and

* Max_Tasks => 0.

Add the following after H.4(27):

NOTES 10 Uses of restriction_parameter_identifier No_Dependence defined in 13.12.1: No_Dependence => Ada.Unchecked_Deallocation and No_Dependence => Ada.Unchecked_Conversion may be appropriate for high-integrity systems. Other uses of No_Dependence can also be appropriate for high-integrity systems.

Add the following new static restriction_identifier after D.7(10):

No_Specific_Termination_Handlers

There are no calls to the following subprograms in Task_Termination: Set_Specific_Handler and Specific_Handler.

Modify the definition of restriction_identifier in AI-305 to the following:

No_Task_Termination

All tasks are non-terminating. It is implementation-defined what happens if a task attempts to terminate. If there is a fall-back handler (see C.7.3) set for the partition it should be called when the first task attempts to terminate.

The static semantic section of the Ravenscar profile definition (in AI-249) becomes:

Static Semantics The run-time profile Ravenscar is equivalent to the following set of pragmas:

pragma Task_Dispatching_Policy (FIFO_Within_Priorities);

pragma Locking_Policy (Ceiling_Locking);

pragma Detect_Blocking;

pragma Restrictions (

No_Abort_Statements, No_Dynamic_Attachment, No_Dynamic_Priorities, No_Implicit_Heap_Allocations, No_Local_Protected_Objects, No_Local_Timing_Events, No_Protected_Type_Allocators, No_Relative_Delay, No_Requeue_Statements, No_Select_Statements, No_Specific_Termination_Handlers, No_Task_Allocators, No_Task_Hierarchy, No_Task_Termination, Simple_Barriers, Max_Entry_Queue_Length => 1, Max_Protected_Entries => 1, Max_Task_Entries => 0, No_Dependence => Ada.Asynchronous_Task_Control, No_Dependence => Ada.Calendar, No_Dependence => Ada.Execution_Time.Group_Budget, No_Dependence => Ada.Execution_Time.Timers, No_Dependence => Ada.Task_Attributes);

"restrictions" in 13.12(7) should be in the times font.

!discussion

The identifier No_IO covers a set of library packages and thus was not moved to Annex J.

The identifier No_Dynamic_Priorities was extended by AI-327 to cover uses of the Priority attribute for protected objects as well as dependencies on Ada.Dynamic_Priorities. Thus it was not moved to Annex J.

The minimum requirement for task termination when No_Task_Termination is in force is to ensure that any fall-back handler is executed at least once. Given that no tasks are meant to terminate this would seem to be sufficient.

!corrigendum 13.12(7)

Replace the paragraph:

The set of restrictions is implementation defined.

by:

The set of restrictions is implementation defined.

!corrigendum D.7(10)

!comment The AI-305 changes are made in the conflict text only.

@drepl @xhang<@xterm<No_Asynchronous_Control> There are no semantic dependences on the package Asynchronous_Task_Control.> @dby @xhang<@xterm<No_Specific_Termination_Handlers> There are no calls to the Set_Specific_Handler and Specific_Handler subprograms in Task_Termination.

!corrigendum D.7(15)

Replace the paragraph:

This paragraph was deleted

by:

The following restriction_identifiers are language defined:

No_Task_Termination: All tasks are non-terminating. It is implementation-defined what happens if a task attempts to terminate. If there is a fall-back handler (see C.7.3) set for the partition it should be called when the first task attempts to terminate.

!corrigendum D.13.1(01)

Insert new clause:

This clause defines the Ravenscar profile.

Legality Rules

The profile_identifier Ravenscar names a run-time profile. For run-time profile Ravenscar, there shall be no profile_pragma_argument_associations.

Static Semantics

The run-time profile Ravenscar is equivalent to the following set of pragmas:

pragma Task_Dispatching_Policy (FIFO_Within_Priorities); pragma Locking_Policy (Ceiling_Locking); pragma Detect_Blocking; pragma Restrictions ( No_Abort_Statements, No_Dynamic_Attachment, No_Dynamic_Priorities, No_Implicit_Heap_Allocations, No_Local_Protected_Objects, No_Local_Timing_Events, No_Protected_Type_Allocators, No_Relative_Delay, No_Requeue_Statements, No_Select_Statements, No_Specific_Termination_Handlers, No_Task_Allocators, No_Task_Hierarchy, No_Task_Termination, Simple_Barriers, Max_Entry_Queue_Length => 1, Max_Protected_Entries => 1, Max_Task_Entries => 0, No_Dependence => Ada.Asynchronous_Task_Control, No_Dependence => Ada.Calendar, No_Dependence => Ada.Execution_Time.Group_Budget, No_Dependence => Ada.Execution_Time.Timers, No_Dependence => Ada.Task_Attributes);

NOTES
37 The effect of the Max_Entry_Queue_Length => 1 restriction applies only to protected entry queues due to the accompanying restriction of Max_Task_Entries => 0.

!corrigendum H.4(2)

Delete the paragraph:

The following restrictions, the same as in D.7, apply in this Annex: No_Task_Hierarchy, No_Abort_Statement, No_Implicit_Heap_Allocation, Max_Task_Entries is 0, Max_Asynchronous_Select_Nesting is 0, and Max_Tasks is 0. The last three restrictions are checked prior to program execution.

!corrigendum H.4(3)

Replace the paragraph:

The following additional restrictions apply in this Annex.

by:

The following restriction_identifiers are language defined:

!corrigendum H.4(9)

Delete the paragraph:

No_Unchecked_Deallocation: Semantic dependence on Unchecked_Deallocation is not allowed.

!corrigendum H.4(16)

Delete the paragraph:

No_Unchecked_Conversion: Semantic dependence on the predefined generic Unchecked_Conversion is not allowed.

!corrigendum H.4(24)

Insert before the paragraph:

If an implementation supports pragma Restrictions for a particular argument, then except for the restrictions No_Unchecked_Deallocation, No_Unchecked_Conversion, No_Access_Subprograms, and No_Unchecked_Access, the associated restriction applies to the run-time system.

the new paragraph:

An implementation of this Annex shall support:

the restrictions defined in this subclause; and

the following restrictions defined in D.7: No_Task_Hierarchy, No_Abort_Statement, No_Implicit_Heap_Allocation; and

the pragma Profile(Ravenscar); and

the following uses of restriction_parameter_identifiers defined in D.7, which are checked prior to program execution:

Max_Task_Entries => 0,

Max_Asynchronous_Select_Nesting => 0, and

Max_Tasks => 0.

!corrigendum H.4(27)

Insert after the paragraph:

NOTES
10 Uses of restriction_parameter_identifier No_Dependence defined in 13.12.1: No_Dependence => Ada.Unchecked_Deallocation and No_Dependence => Ada.Unchecked_Conversion may be appropriate for high-integrity systems. Other uses of No_Dependence can also be appropriate for high-integrity systems.

!corrigendum J.13(1)

Insert new clause:

The following restrictions involve dependence on specific language-defined units. The more general restriction No_Dependence (see 13.12.1) should be used for this purpose.

Static Semantics

The following restriction_identifiers exist:

No_Asynchronous_Control: Semantic dependence on the predefined package Asynchronous_Task_Control is not allowed.

No_Unchecked_Conversion: Semantic dependence on the predefined generic function Unchecked_Conversion is not allowed.

No_Unchecked_Deallocation: Semantic dependence on the predefined generic procedure Unchecked_Deallocation is not allowed.

!ACATS test

This AI should be covered by tests for the Ravenscar profile.

!appendix


From: Alan Burns
Sent: Tuesday, January 4, 2005  8:50 AM

As part of integration it is necessary to identify those new language
features that can be used with
Ravenscar, and more importantly those that cannot.

I have organized a series of emails around the IRTAW email list and have
complete
agreement with the following.

First what we already covered in the AIs; restriction identifier
No_Local_Timing_Events and the inclusion
of no dynamic ceilings in the no dynamic priority  restriction identifier.

In terms of the budgeting provisions, the IRTAW view is that
Ada.Execution_Time is
a very important package for ravenscar-like programs, but
Ada.Execution_Time.Timers
and Ada.Execution_Time.Group_Budgets do not sensible co-exist with the other
restrictions of Ravenscar and so should be prohibited.

Its is therefore necessary to add two further restrictions to Ravenscar.
But we can do this
in two ways; either by introducing two new restriction identifiers, or
by using the new
provision by which any language defined library package can be
restricted. I'll let
Pascal or Randy decide this - or perhaps we need a short discussion at
the Paris meeting?

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

From: Robert Dewar
Sent: Tuesday, January 4, 2005  9:42 AM

Please don't add more junk restrictions, when pragma No_Dependence takes
care ot if. In fact here is an idea, move all the specific package
restrictions to annex J!

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

From: Pascal Leroy
Sent: Tuesday, January 4, 2005  11:13 AM

I agree with Robert here: don't add new restrictions, and move the
existing ones to J.

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

From: Randy Brukardt
Sent: Tuesday, January 4, 2005  1:20 PM

Absolutely: that's the reason we defined it; we didn't want a dozen new
dependence restrictions.

Moving the existing ones to Annex J makes sense. Who's going to write the AI
(it should be easy)?

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

From: Alan Burns
Sent: Wednesday, January 5, 2005  5:35 AM

I am happy to do this - but are we clear that all existing package
specific restriction identifiers should be moved
to Annex J - anyone disagree?

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

From: John Barnes
Sent: Wednesday, January 5, 2005  9:47 AM

Presumably we can do nothing about No_Dynamic_Attachment since dependence
means children also and we need Ada.Interrupts.Names.

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

From: Robert Dewar
Sent: Wednesday, January 5, 2005  10:09 AM

I don't understand,

pragma Restrictions (No_Dependence => Ada.Dynamic_Priorites); seems to
exactly catch the intent of the No_Dynamic_Attachment restriction:

9   No_Dynamic_Priorities
                 There are no semantic dependences on the package Dynamic_
                 Priorities.

I really don't see what Ada.Interrupts.Names has to do with this.

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

From: John Barnes
Sent: Wednesday, January 5, 2005  2:02 PM

AI-305 says

No_Dynamic_Attachment
   There is no call to any of the operations defined in package
Ada.Interrupts.

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

From: Robert Dewar
Sent: Wednesday, January 5, 2005   4:14 PM

SOrry, I misread, yes, of course No_Dynamic_Attachment has nothing
whatever to do with avoiding package dependences, so it is nothing
whatever to do with No_Dependence.

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

From: Arnuad Charlet
Sent: Wednesday, January 19, 2005  5:10 AM

BTW, have we discussed/addressed the issue of interfaces to protected
objects and tasks in the context of Ravenscar ?

I assume that if we don't do anything, these will be by default part of
Ravenscar. Is that what we want ?

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

From: Alan Burns
Sent: Wednesday, January 19, 2005  6:42 AM

interfaces are compile time constructs, so they do not impact on
Ravenscar which
is concerned with run-time issues

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

From: Arnuad Charlet
Sent: Wednesday, January 19, 2005  6:52 AM

interfaces do have run time impact, in particular dynamic dispatching.

But from your message, I gather that nothing special has been discussed
nor will be changed wrt ravenscar.

It would still be good to update the ravenscar definition to explicitely
mention protected and task interfaces IMO.

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

From: Steve Michell
Sent: Thursday, January 20, 2005  8:48 AM

I agree that the issue of interfaces should be discussed, and our compiler
specialists should voice an opinion. Since all task specifications and objects
reside at the library level, and since there is no way to dereference a task
(entries are forbidden) from the caller's perspective, there should be no
run-time dynamic issues, apart from possibly at partition start time.

For PO specs and objects, they also reside at the library level, so it should
be possible to statically resolve all references, or we should be able to
figure out how to statically resolve the references and create a restriction
that matches this.

I do agree with Arnaud that Ravenscar needs to specifically mention task and
protected interfaces, positively or negatively, to remove the ambiguity in
developers minds.

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

From: Alan Burns
Sent: Thursday, January 20, 2005  9:59 AM

This sound more like a note for the AARM - Steve can you produce one?

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

From: Randy Brukardt
Sent: Thursday, January 20, 2005  5:52 PM

> For PO specs and objects, they also reside at the library level,
> so it should be possible to statically resolve all references, or
> we should be able to figure out how to statically resolve the
> references and create a restriction that matches this.

As soon as you allow I'Class, you're going to have dynamic references. It
doesn't matter where the objects are declared, because they still can be passed
as an I'Class  parameter. You could of course restrict I'Class, but, since the
whole point of  interfaces is to get dynamic dispatching, a controlled form of
dynamic references, it wouldn't be very useful to do so.

So, if all references must be static, I would just ban synchronized interfaces
(they can't do any real good) -- but barring that, you'd have to ban I'Class
for all synchronized interfaces. I would hope that the limited and controlled
dynamism inherent in synchronized interfaces could be allowed, but that is
obviously a question for real-time experts (not me!) to answer. And it will
take more effort than an AARM note to figure out.

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

From: Alan Burns
Sent: Friday, January 21, 2004  3:03 AM

As you know Ravenscar is silent about the sequential parts of the language,
and hence make no statement about memory usage in general (eg class wide
stuff). The use of Ravenscar in a critical domain is likely to also
have added restrictions to the sequential features. In Ada2005 this
would include use of interfaces in general. So Ravenscar does not in
itself require references to be static. Now task, protected and
synchronized interfaces are undoubted about the concurrent parts of
the language, but I feel their acceptability is more an
issue for the decisions made about references in general. Hence I feel
Ravenscar should be silent about them with an AARM note covering the
consequences of using such interfaces in a Ravenscar program.

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

From: Randy Brukardt
Sent: Thursday, January 20, 2005  5:38 PM

I'm a bit uncomfortable moving the No_IO restriction to Annex J. It covers six
units, and it would be really easy to forget one of them. Moreover, it is
less subject to maintenance than all of those No_Dependence pragmas - people
using it won't have to make any changes to handle the introduction of
Really_Darn_Wide_Text_IO, er, Wide_Wide_Text_IO.

Looking at it, I'm a bit surprised that it doesn't include
implementation-defined I/O units. I would have expected it to prevent the
use of System.Basic_IO on Janus/Ada, for example, as that is just a
lower-level file I/O package. (The list of implementation-defined I/O units
would of course be defined by the implementation; the intent would be that
packages similar in function to the predefined I/O units be covered.) The
wording of the restriction doesn't seem to permit the implementation to add
implementation-defined units to the restriction -- which would add value to
the restriction beyond simple No_Dependence.

I would leave it in Annex H and allow it to cover implementation-defined I/O
units. (The units covered would have to be documented, of course.)

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

From: Robert Dewar
Sent: Thursday, January 20, 2005  5:50 PM

> The
> wording of the restriction doesn't seem to permit the implementation to add
> implementation-defined units to the restriction -- which would add value to
> the restriction beyond simple No_Dependence.

Sure you can add this, what would stop you, if your implementation provides
a package, it does not have to do it all the time. It would be perfectly
conforming to have a package that is only available in leap years. Yes,
that would be stupid, but non-stupid examples like this are certainly
allowed.

> I would leave it in Annex H

That's OK with me

> and allow it to cover implementation-defined I/O
> units. (The units covered would have to be documented, of course.)

IA that this should include implementation defined I/O units is reasonable.
Of course you might have limited I/O units that were specificially designed
to be used in *conjunction* with this restriction.

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

From: Randy Brukardt
Sent: Thursday, January 20, 2005  6:01 PM

> IA that this should include implementation defined I/O units is
> reasonable.

That's what I had in mind. Something like:

"No_IO also should not allow semantic dependence on implementation-defined
Input/Output units similar in function to the language-defined units listed."

> Of course you might have limited I/O units that were specificially designed
> to be used in *conjunction* with this restriction.

Absolutely. Thus the "similar in function", and of course, IA can always be
ignored.

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

From: Robert A. Duff
Sent: Thursday, January 20, 2005  7:22 PM

> Re: No_IO
>
> I'm a bit uncomfortable moving this restriction to Annex J. It covers six
> units, and it would be really easy to forget one of them.

I agree.

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

From: Jean-Pierre Rosen
Sent: Friday, January 21, 2005  3:39 AM

> I'm a bit uncomfortable moving this restriction to Annex J. It covers six
> units, and it would be really easy to forget one of them. Moreover, it is
> less subject to maintenance than all of those No_Dependence pragmas - people
> using it won't have to make any changes to handle the introduction of
> Really_Darn_Wide_Text_IO, er, Wide_Wide_Text_IO.
>
What you are saying is that No_IO is more a *profile* than a single
restriction. If a profile can include another profile, that would do the
trick.

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

From: Randy Brukardt
Sent: Monday, February 28, 2005  8:45 PM

The recently approved AI-394 banishes several restrictions to Annex J in
favor of using the new No_Dependence restriction.

One of the restrictions so banished is No_Dynamic_Priorities:

No_Dynamic_Priorities
There are no semantic dependences on the package Dynamic_Priorities.

However, AI-327 extended this restriction to:

No_Dynamic_Priorities
There are no semantic dependences on the package Dynamic_Priorities, and
no occurrences of the attribute Priority.

This covers the dynamic changing of ceiling priorities for protected
objects. It seems to me that this still needs to be disallowed by profile
Ravenscar, so it seems that someone fell asleep at the switch.

I think that we need to put this back the way it was in AI-327, and leave
this restriction in the Ravenscar profile, rather than use No_Dependence. Is
this right??

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

From: Robert Dewar
Sent: Tuesday, March  1, 2005 12:00 AM

Yes, that's indeed right

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

From: Alan Burns
Sent: Tuesday, March  1, 2005  2:33 AM

...
> This covers the dynamic changing of ceiling priorities for protected
> objects. It seems to me that this still needs to be disallowed by profile
> Ravenscar, so it seems that someone fell asleep at the switch.

Well that would be me - yes totally missed this interaction
Obviously i would have noticed it later ...

> I think that we need to put this back the way it was in AI-327, and leave
> this restriction in the Ravenscar profile, rather than use No_Dependence.
> Is this right??

YES

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

From: Pascal Leroy
Sent: Tuesday, March  1, 2005  3:31 AM

> I think that we need to put this back the way it was in
> AI-327, and leave this restriction in the Ravenscar profile,
> rather than use No_Dependence. Is this right??

Yes.

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

From: Randy Brukardt
Sent: Tuesday, March  1, 2005  4:22 PM

> Well that would be me - yes totally missed this interaction
> Obviously i would have noticed it later ...

Don't feel bad, I only noticed it because the tool that makes the Amendment
document produced an error message. I'll process this as a correction to
AI-394.

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

Questions? Ask the ACAA Technical Agent