Version 1.11 of ais/ai-00305.txt
!standard D.7 (10) 05-05-05 AI95-00305/10
!standard D.7 (15)
!standard D.7 (19)
!standard H.5 (01)
!standard 9.5.1 (22)
!class amendment 02-07-17
!status Amendment 200Y 02-10-23
!status WG9 Approved 02-12-13
!status ARG Approved 10-0-1 02-10-11
!status work item 02-07-17
!status received 02-07-17
!priority High
!difficulty Medium
!subject New pragma and additional restriction identifiers for real-time systems
!summary
A new pragma and addition restriction identifiers are defined to enhance the
ability to create highly efficient and predictable tasking runtime systems.
!problem
Experience constructing the "highly efficient tasking runtime systems"
of D.7 has shown that the set of restrictions is insufficient. In particular,
the Ravenscar Profile is commonly used in Safety-Critical and High-Integrity
applications to provide a highly efficient tasking runtime. However, the
profile requires restrictions beyond those defined by the Standard,
requiring users to fall back on vendor-defined extensions.
!proposal
This amendment 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 new pragma is also defined to force an implementation to detect blocking
within a protected operation.
!wording
The following new static restriction_identifiers are defined and
inserted after D.7(10):
No_Calendar
There are no semantic dependencies on package Calendar.
No_Dynamic_Attachment
There is no call to any of the operations defined in package
Interrupts (Is_Reserved, Is_Attached, Current_Handler,
Attach_Handler, Exchange_Handler, Detach_Handler, and Reference).
No_Local_Protected_Objects
protected objects shall be declared only at library level.
No_Protected_Type_Allocators
There are no allocators for protected types or types containing
protected type subcomponents.
No_Relative_Delay
There are no delay_relative_statements.
No_Requeue_Statements
There are no requeue_statements.
No_Select_Statements
There are no select_statements.
No_Task_Attributes_Package
There are no semantic dependencies on package Task_Attributes.
Simple_Barriers
The Boolean expression in an entry barrier shall be either a
static Boolean expression or a Boolean component of the enclosing
protected object.
The following new dynamic restriction_identifier is defined and
replaces D.7(15/1):
No_Task_Termination
All tasks are non-terminating. It is implementation-defined what
happens if a task attempts to terminate.
The following new dynamic restriction_parameter_identifier is defined and
inserted after D.7(19/1):
Max_Entry_Queue_Length
Max_Entry_Queue_Length defines the maximum number of calls
that are queued on an entry. Violation of this restriction
results in the raising of Program_Error at the point
of the call.
The following pragma is defined in a new subsection H.5:
H.5 Pragma Detect_Blocking
The following pragma forces an implementation to detect potentially
blocking operations within a protected operation.
Syntax
The form of a pragma Detect_Blocking is as follows:
pragma Detect_Blocking;
Post-Compilation Rules
A pragma Detect_Blocking is a configuration pragma.
Dynamic Semantics
An implementation is required to detect a potentially blocking
operation within a protected operation[, and to raise Program_Error
(see 9.5.1)].
Implementation Permissions
An implementation is allowed to reject a compilation_unit if a potentially
blocking operation is present directly within an entry_body or the body of a
protected subprogram.
Notes
An operation that causes a task to be blocked within a foreign language
domain is not defined to be potentially blocking, and need not be detected.
!discussion
The restriction 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". This also matches
the semantics for restriction No_Local_Protected_Objects.
No_Protected_Type_Allocators is similar to the existing restriction
No_Task_Allocators.
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).
No_Select_Statements excludes selective_accept, timed and
conditional (protected) entry calls, and asynchronous_select.
Some restriction identifiers concerning tasking are actually defined in
H.4. For reasons of minimum change we did not move them.
When pragma Detect_Blocking is in force, we allow implementations to reject
protected bodies that contain potentially blocking operations. Such a static
check prevents problems from appearing in fielded systems from a potentially
blocking operation which is rarely executed. We limit the check to protected
bodies so that libraries which contain potentially blocking operations (such
as a lock) which cannot be executed do not cause the program to be rejected.
Add a new note after 9.5.1(22):
22 The pragma Detect_Blocking may be used to ensure that all
executions of potentially blocking operations raise Program_Error. See H.5.
!ACATS test
ACATS tests should be constructed for these features.
!corrigendum D.7(10)
Insert after the paragraph:
- No_Asynchronous_Control
-
There are no semantic dependences on the package Asynchronous_Task_Control.
the new paragraphs:
- No_Calendar
-
There are no semantic dependencies on package Calendar.
- No_Dynamic_Attachment
-
There is no call to any of the operations defined in package
Interrupts (Is_Reserved, Is_Attached, Current_Handler,
Attach_Handler, Exchange_Handler, Detach_Handler, and Reference).
- No_Local_Protected_Objects
-
Protected objects shall be declared only at library level.
- No_Protected_Type_Allocators
-
There are no allocators for protected types or types containing
protected type subcomponents.
- No_Relative_Delay
-
There are no delay_relative_statements.
- No_Requeue_Statements
-
There are no requeue_statements.
- No_Select_Statements
-
There are no select_statements.
- No_Task_Attributes_Package
-
There are no semantic dependencies on package Task_Attributes.
- Simple_Barriers
-
The Boolean expression in an entry barrier shall be either a static Boolean
expression or a Boolean component of the enclosing protected object.
!corrigendum D.7(15)
Replace the paragraph:
This paragraph was deleted
by:
The following restriction_identifier is language defined:
- No_Task_Termination
-
All tasks are non-terminating. It is implementation-defined what
happens if a task attempts to terminate.
!corrigendum D.7(19)
Insert after the paragraph:
- Max_Tasks
-
Specifies the maximum number of task creations that may be executed over the
lifetime of a partition, not counting the creation of the environment task.
A value of zero prevents any task creation and, if a program contains a task
creation, it is illegal. If an implementation chooses to detect a violation
of this restriction, Storage_Error should be raised; otherwise, the behavior
is implementation defined.
the new paragraph:
- Max_Entry_Queue_Length
-
Max_Entry_Queue_Length defines the maximum number of calls
that are queued on an entry. Violation of this restriction
results in the raising of Program_Error at the point of the call.
!corrigendum H.5(1)
Insert new clause:
The following pragma forces an implementation to detect potentially
blocking operations within a protected operation.
Syntax
The form of a pragma Detect_Blocking is as follows:
pragma Detect_Blocking;
Dynamic Semantics
An implementation is required to detect a potentially blocking
operation within a protected operation, and to raise Program_Error
(see 9.5.1).
Post-Compilation Rules
A pragma Detect_Blocking is a configuration pragma.
Implementation Permissions
An implementation is allowed to reject a compilation_unit if a potentially
blocking operation is present directly within an entry_body or the body of
a protected subprogram.
NOTES
10 An operation that causes a task to be blocked within a foreign language
domain is not defined to be potentially blocking, and need not be detected.
!corrigendum 9.5.1(22)
Insert after the paragraph:
21 From within a protected action, an internal call on a
protected subprogram, or an external call on a protected subprogram with a
different target object is not considered a potentially blocking operation.
the new paragraph:
22 The @nt{pragma} Detect_Blocking may be used to ensure that all
executions of potentially blocking operations raise Program_Error. See H.5.
!appendix
Editor's Note: This AI was split out of the Ravenscar AI, AI-249.
****************************************************************
Editor's Note (December 6, 2002):
The rule that pragma Detect_Blocking is a configuration pragma was moved
to Post-Compilation Rules and rewritten to be consistent with other
configuration pragmas, including pragma Profile.
****************************************************************
Questions? Ask the ACAA Technical Agent