Version 1.4 of ais/ai-00249.txt

Unformatted version of ais/ai-00249.txt version 1.4
Other versions for file ais/ai-00249.txt

!standard D.2.2 (5)          01-06-04 AI95-00249/03
!standard D.7 (00)
!class amendment 00-12-04
!status work item 00-12-04
!status received 00-12-04
!priority High
!difficulty Medium
!subject Ravenscar Profile for High-Integrity Systems
!summary
New pragmas and restrictions are proposed to directly support the Ravenscar Profile -- an execution time profile suitable for use in High-Integrity and Safety-Critical applications.
!problem
The Ravenscar Profile is commonly used in Safety-Critical and High-Integrity applications. However, the profile is incompletely supported by the standard, requiring users to fall back on vendor-specific extensions.
!proposal
This amendment proposes a pragma-based mechanism to allow the application to request use of the Ravenscar Profile. It proposes the addition of a pragma to support the concept of a runtime profile. The amendment then proposes the runtime profile identifier "Ravenscar" to be defined in the standard and specifies its semantics.
The proposal also introduces several new restriction identifiers to define runtime behaviors that are to be restricted when using the Ravenscar profile. These identifiers may be used to specify runtime behavior which is independent of the Ravenscar definition.
A runtime profile is an alternative mode of operation that is defined by the standard. It is selected by inclusion of the configuration pragma Profile that applies to an active partition. The profile identifier "Ravenscar" selects the mode of operation to be the Ravenscar Profile.
!wording
Static Semantics
pragma Profile (profile_identifier [profile_argument_definition]);
The profile_identifier shall be either Ravenscar or an implementation-defined identifier.
Pragma Profile is a configuration pragma. It is equivalent to the set of pragmas that are defined below. There may be more than one pragma Profile for a partition.
Dynamic Semantics
When profile_identifier Ravenscar is in effect, the following dynamic semantics apply:
1.1. Task Dispatching Policy
The default Task_Dispatching_Policy for the active partition shall be FIFO_Within_Priorities.
1.2. Locking Policy
The default Locking_Policy for the active partition shall be Ceiling_Locking.
1.3. Restrictions Pragma
1.3.1. Standard Identifiers
The following pragma Restrictions identifiers defined in the standard apply to the alternative mode of operation defined by the Ravenscar Profile:
Max_Asynchronous_Select_Nesting => 0 Max_Task_Entries => 0 Max_Protected_Entries => 1 No_Abort_Statements No_Asynchronous_Control No_Dynamic_Priorities No_Implicit_Heap_Allocations No_Task_Allocators No_Task_Hierarchy
1.3.2. New Identifiers
The following new pragma Restrictions identifiers are defined and apply to the alternative mode of operation defined by the Ravenscar Profile:
Max_Entry_Queue_Length = N
Max_Entry_Queue_Length defines the maximum number N of calls that are queued on an entry. Violation of this restriction results in the raising of Program_Error exception at the point of the call.
For the Ravenscar Profile, the value of N is 1. Note that the affect of this restriction applies only to protected entry queues due to the accompanying restriction of Max_Task_Entries => 0.
No_Calendar
There are no semantic dependencies on package Ada.Calendar.
No_Dynamic_Attachment
There is no call to any of the operations defined in package Ada.Interrupts (Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler, Detach_Handler, Reference).
No_Local_Protected_Objects
All protected objects are created via library-level declarations.
No_Protected_Type_Allocators
There are no allocators for protected types or types containing protected type components.
No_Relative_Delay
Delay_relative statements are not allowed.
No_Requeue_Statements
Requeue statements are not allowed.
No_Select_Statements
Select_statements are not allowed.
No_Task_Attributes_Package
There are no semantic dependencies on package Ada.Task_Attributes.
Simple_Barriers
The Boolean expression in an entry barrier shall be be either a Boolean literal value or the value of a Boolean component of the enclosing protected object.
1.4. Bounded Error Detection
The bounded error that is the invocation of one of the following potentially blocking operations during a protected action shall be detected: - a protected entry_call_statement - a delay_until_statement - a call to a language-defined subprogram that is potentially blocking,
for example Ada.Synchronous_Task_Control.Suspend_Until_True
Notes (1) The Ravenscar Profile subset excludes the following potentially blocking
operations within a protected action: - a select statement - an accept statement - a task entry call - a relative delay statement - an abort statement - task creation or activation - an external requeue statement with the same target object as that of
the protected action
(2) Detection of these bounded error cases results in Program_Error being
raised (see 9.5.1(17)).
(3) Potentially blocking operations that occur in a foreign language domain
may not be detected.
!example
!discussion
a) Pragma Profile is presented as an "alternative" mode of operation rather than a "non-standard" mode as in section 1.1.5(11) since its inclusion in the Standard makes it not non-standard. Other profiles may be defined by an implementation, for example to define the Spark subset, or to define variations of the Ravenscar definition such as Ravenscar_Non_Preemptive.
b) The pragma No_Task_Hierarchy must impose the constraint that all tasks depend directly on the Environment task as a result of all task objects being created by library level declarations. The restriction means that no support is needed for "masters" and "waiting for dependent tasks" even for tasks declared within the main subprogram. This also matches the semantics for pragma No_Local_Protected_Objects.
c) The restrictions forcing the maximum length of an entry queue to be one and the maximum number of entries to be one are there for deterministic operation of entry queue servicing and to simplify the runtime implementation. The semantics are intended to be consistent with those for blocking on a suspension object via Suspend_Until_True.
d) Static attachment of interrupt handlers via pragma Attach_Handler is supported.
e) No_Protected_Type_Allocators matches existing restriction No_Task_Allocators.
f) No_Delay in H.4 is too strong for the Ravenscar Profile since we want to allow delay_until Ada.Real_Time.Time, but not relative delay (non- deterministic) nor package Ada.Calendar (too coarse).
g) No_Select_Statements excludes selective_accept (there are no task entries anyway), timed and conditional (protected) entry calls, and asynchronous_select (which is re-inforced by also requiring Max_Asynchronous_Select_Nesting = 0).
!ACATS test
!appendix

!topic Addition of support for Ravenscar Profile
!reference RM-D
!from Brian Dobbing 00-09-24, Alan Burns 00-11-17, Joyce Tokar 00-11-17
!keywords Ravenscar, high integrity
!discussion

This comment proposes the addition of support in the language standard for the
de facto standard Ravenscar Profile. This profile is included in the ISO
document "Guide for the use of the Ada programming language in high integrity
systems".

The comment proposes addition of pragma Ravenscar to Annex D of the RM as
follows.

Pragma Ravenscar defines an alternative mode of operation that consists of the
following amendments to the dynamic semantics of the standard. [Note: I say
"alternative"  rather than "non-standard" as in section 1.5. This is because
its inclusion in the standard makes it not non-standard.]

Static Semantics
	pragma Ravenscar;

Pragma Ravenscar is a configuration pragma that applies to an active partition.

Dynamic Semantics
1	Task Dispatching Policy
The default Task_Dispatching_Policy for the active partition is
FIFO_Within_Priorities. An implementation may define alternative task
dispatching policies.

2	Locking Policy
The default Locking_Policy for the active partition is Ceiling_Locking. An
implementation may define alternative locking policies.

3	Restrictions pragmas
3.1	Standard Pragmas
The following pragma Restrictions identifiers defined in the standard apply to
the alternative mode of operation defined by pragma Ravenscar:
	Max_Asynchronous_Select_Nesting => 0
	Max_Task_Entries => 0
	Max_Protected_Entries => 1
	No_Abort_Statements
	No_Asynchronous_Control
	No_Dynamic_Priorities
	No_Implicit_Heap_Allocations
	No_Task_Attributes
	No_Task_Allocators
	No_Task_Hierarchy
The pragma No_Task_Hierarchy imposes the constraint that all tasks must depend
immediately on the Environment task as a result of all task objects being
created by library level declarations. [Note: It is not clear to me whether the
existing RM wording fully implies this. It is not sufficient to say that all
tasks shall depend (directly or indirectly) on the Environment task since this
presumably would include those declared inside library-level subprograms. What
we want to restrict is having to support "masters" and "waiting for dependent
tasks"].

3.2	Additional Pragmas
The following new pragma Restrictions identifiers are defined as applying to the
alternative mode of operation defined by pragma Ravenscar:
[Aside: Alan Burns has a more complete write-up of these pragmas than is
presented here.]
	Max_Entry_Queue_Depth = 1
Max_Entry_Queue_Depth defines the maximum number of calls that are queued on a
(protected) entry. Violation of this restriction results in the raising of
Program_Error exception at the point of the call. [Note: These semantics are
intended to be consistent with those for blocking on a suspension object via
Suspend_Until_True.]
	No_Calendar
There are no semantic dependencies on package Ada.Calendar.
	No_Dynamic_Attachment
There is no call to any of the operations defined in package Ada.Interrupts
(Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler,
Detach_Handler, Reference) [Note: Static attachment via pragma Attach_Handler is
supported.] {Note: At IRTAW-10, we called this No_Dynamic_Interrupt_Handlers,
but that doesn't really convey the correct meaning of the restriction, hence my
alternative suggestion.]
	No_Local_Protected_Objects
All protected objects are created via library-level declarations.
[Note: This matches the additional semantics for No_Task_Hierarchy. If these
additional semantics were considered to be unacceptable, we could introduce
No_Local_Task_Objects to go with this one.]
	No_Protected_Type_Allocators
There are no allocators for protected types or types containing protected type
components. [Note: This is like No_Task_Allocators]
	No_Relative_Delay
Delay_relative statements are not allowed.
[Note: Unfortunately, No_Delay in H.4 is too strong since we want to allow
delay_until Ada.Real_Time.Time, but not relative delay (non-deterministic) or
Ada.Calendar (too coarse).]
	No_Requeue
Requeue statements are not allowed.
	No_Select_Statements
Select_statements are not allowed.
[Note: This includes selective_accept (there are no task entries anyway), timed
and conditional entry calls, and asynchronous_select (which is re-inforced by
Max_Async_Select_Nesting = 0.]
	No_Task_Termination
No_Task_Termination defines task termination (including for the Environment
task) to be a bounded error condition. The possible effects are:
	The task terminates as defined by the standard mode of operation.
	Prior to termination as defined by the standard mode of operation, the task
        calls an implementation-defined subprogram. The mechanism for specifying the
        subprogram to be called, and any restrictions on the operation of the
        subprogram, are implementation-defined.
[Note: This is defined so as to mitigate the hazard of "silent task death" in
high integrity systems and to provide the opportunity for application-specific
recovery action.]
	Simple_Barrier_Variables
The Boolean expression in an entry barrier shall be the value of a Boolean
component of the enclosing protected object.

4 Outstanding Issue -- Task_Activation
To satisfy the requirements of the Safety Critical and High-Integrity domains,
there is a need to define the behavior of program elaboration to be atomic.
That is to say, that no interrupts are delivered during this period of
execution. In addition, task activation shall be deferred until the completion
of all elaboration code.

A proposed approach to addressing this concern is to introduce an optional
argument on the pragma Ravenscar such that the activation of library level tasks
may be specified. This would have the effect of the modifing the syntax and
semantics for pragma Ravenscar as follows:

Static Semantics
	pragma Ravenscar[(Task_Activation => Deferred | Standard)];

Dynamic Semantics

4.1 Task_Activation => Deferred
With the Deferred value for the Task_Activation argument, all task activation
and all interrupt handler attachment for library-level tasks and interrupt
handlers are deferred. The deferred task activation and handler attachment
occurs immediately after the "begin" of the Environment task. At this point,
the Environment task is suspended until all deferred task activation and handler
attachment is complete. In this mode of operation, it is a bounded error for the
Environment task to execute a call to
Ada.Synchronous_Task_Control.Suspend_Until_True or to execute a protected entry
call that is blocking during its declarative part. Program_Error may be raised
by the call, or the active partition may deadlock. [Note: In either case, the
active partition is terminated.] It is a bounded error for any deferred task
activation to fail. The Environment task and all tasks whose activations fail
are terminated. A task whose activation succeeds may continue to execute, or
may instead be immediately terminated, thereby completing execution of the
partition. [Note: The preference is to terminate the partition immediately to
mitigate the hazard posed by continuing execution with a subset of the tasks
being active. However this would introduce code into the runtime to detect this
corner case, so it is not mandated.]

4.2	Task_Activation => Standard
This value defines the execution of the declarative part of the Environment task
to be as defined by the standard mode of operation with respect to task
activation and interrupt handler attachment.

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

Questions? Ask the ACAA Technical Agent