Version 1.4 of ai12s/ai12-0291-1.txt

Unformatted version of ai12s/ai12-0291-1.txt version 1.4
Other versions for file ai12s/ai12-0291-1.txt

!standard D.13(0)          20-09-09 AI12-0291-1/04
!standard D.13(1/3)
!standard D.13(4/3)
!standard D.13(6/4)
!standard D.13(9/3)
!standard D.13(10/3)
!standard D.13(11/4)
!standard D.13(12/4)
!class Amendment 18-10-11
!status Amendment 1-2012 18-11-26
!status ARG Approved 10-0-0 18-10-22
!status work item 18-10-11
!status received 18-08-09
!priority Low
!difficulty Easy
!subject Jorvik Profile
!summary
The Jorvik profile is introduced.
!problem
The Ravenscar profile is a subset of the Ada concurrency facilities that supports determinism, schedulability analysis, constrained memory utilization, and certification to the highest integrity levels. Four distinct application domains are specifically intended:
* hard real-time applications requiring predictability, * safety-critical systems requiring formal, stringent certification, * high-integrity applications requiring formal static analysis and
verification,
* embedded applications requiring both a small memory footprint and low
execution overhead.
Without question, there are applications that should use the Ravenscar profile and can be expressed reasonably in that profile’s subset. However, some real-time and embedded applications do not require the most stringent certification/safety analyses supported by Ravenscar and cannot reasonably be expressed in the profile’s subset. Such applications are not "Ravenscar applications". Ada should support such applications.
!proposal
A new tasking profile is introduced to address applications that are not Ravenscar applications but still need predictability, a small memory footprint, and low execution overhead. This new profile removes selected Ravenscar restrictions in order to enhance expressive power without sacrificing the predictability required for timing and storage analyses.
This new profile is named "Jorvik" (pronounced "Yorvick"), the Viking name for the city of York, UK, near where the Ravenscar profile was introduced.
It is worth noting that the new profile has been implemented by AdaCore and provided on selected platforms since 2016.
The new profile allows multiple protected entries per protected object and multiple queued callers per protected entry (i.e., the queue length can be greater than 1). In addition, in place of Simple_Barriers the new restriction Pure_Barriers (see AI12-0290-1) is applied. With these changes in place most canonical protected object idioms can be expressed.
The new profile also allows relative delay statements and use of the Ada.Calendar package. Although relative delay statements are not appropriate for expressing periodic behavior, there are cases in which a relative delay has precisely the required semantics for embedded applications. For example, an electromechanical relay may have a requirement that it not be actuated more than N times per second in order to prevent burnout. A relative delay after each actuation directly implements that requirement.
The primary difference between the Ravenscar and Jorvik profiles is the list of parameters to pragma Restrictions. The Jorvik profile parameters are the same as those of the Ravenscar profile but with the following restrictions removed:
No_Implicit_Heap_Allocations No_Relative_Delay Simple_Barriers Max_Entry_Queue_Length => 1 Max_Protected_Entries => 1 No_Dependence => Ada.Calendar No_Dependence => Ada.Synchronous_Barriers
and with restriction Simple_Barriers replaced in the Jorvik profile by a new restriction Pure_Barriers, defined in AI12-0290-1.
!wording
The existing section D.13 is replaced with the following:
D.13 The Ravenscar and Jorvik Profiles
[This subclause defines the Ravenscar and Jorvik profiles.]
Legality Rules
The profile_identifier Ravenscar and profile_identifier Jorvik are usage profiles (see 13.12). For usage profiles Ravenscar and Jorvik there shall be no profile_pragma_argument_associations.
Static Semantics
The usage 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_CPU_Assignment, 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_Budgets, No_Dependence => Ada.Execution_Time.Timers, No_Dependence => Ada.Synchronous_Barriers, No_Dependence => Ada.Task_Attributes, No_Dependence =>
System.Multiprocessors.Dispatching_Domains);
[Editor's note: So far as I'm aware, the Ravenscar definition is unchanged here.]
The usage profile Jorvik 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_CPU_Assignment, No_Dynamic_Priorities, No_Local_Protected_Objects, No_Local_Timing_Events, No_Protected_Type_Allocators, No_Requeue_Statements, No_Select_Statements, No_Specific_Termination_Handlers, No_Task_Allocators, No_Task_Hierarchy, No_Task_Termination, Pure_Barriers, Max_Task_Entries => 0, No_Dependence => Ada.Asynchronous_Task_Control, No_Dependence => Ada.Execution_Time.Group_Budgets, No_Dependence => Ada.Execution_Time.Timers, No_Dependence => Ada.Task_Attributes, No_Dependence =>
System.Multiprocessors.Dispatching_Domains);
AARM Note: The Jorvik profile removes a number of restrictions from the Ravenscar profile to allow additional applications to benefit from predicability and low overhead. Specifically, the following restrictions are removed:
No_Implicit_Heap_Allocations No_Relative_Delay Max_Entry_Queue_Length => 1 Max_Protected_Entries => 1 No_Dependence => Ada.Calendar No_Dependence => Ada.Synchronous_Barriers
Jorvik also replaces restriction Simple_Barriers with Pure_Barriers (a weaker requirement than Simple_Barriers).
Implementation Advice
On a multiprocessor system, an implementation should support a fully partitioned approach if one of these profiles is specified. Each processor should have separate and disjoint ready queues.
NOTES
42 For the Ravenscar profile, the effect of the restriction Max_Entry_Queue_Length => 1 applies only to protected entry queues due to the accompanying restriction Max_Task_Entries => 0. The restriction Max_Entry_Queue_Length is not applied by the Jorvik profile.
43 When the Ravenscar or Jorvik profile is in effect (via the effect of the No_Dynamic_CPU_Assignment restriction), all of the tasks in the partition will execute on a single CPU unless the programmer explicitly uses aspect CPU to specify the CPU assignments for tasks. The use of multiple CPUs requires care, as many guarantees of single CPU scheduling no longer apply.
44 It is not recommended to specify the CPU of a task to be Not_A_Specific_CPU when the Ravenscar or Jorvik profile is in effect. How a partition executes strongly depends on the assignment of tasks to CPUs.
45 Any unit that meets the requirements of the Ravenscar profile also meets the requirements of the Jorvik profile.
!discussion
(See Proposal.)
!corrigendum D.13(1/3)
Replace the paragraph:
This subclause defines the Ravenscar profile.
by:
This subclause defines the Ravenscar and Jorvik profiles.
!corrigendum D.13(4/3)
Replace the paragraph:
The profile_identifier Ravenscar is a usage profile (see 13.12). For usage profile Ravenscar, there shall be no profile_pragma_argument_associations.
by:
The profile_identifier Ravenscar and profile_identifier Jorvik are usage profiles (see 13.12). For usage profiles Ravenscar and Jorvik, there shall be no profile_pragma_argument_associations.
!corrigendum D.13(6/4)
Insert after the paragraph:
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_CPU_Assignment, 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_Budgets, No_Dependence => Ada.Execution_Time.Timers, No_Dependence => Ada.Synchronous_Barriers, No_Dependence => Ada.Task_Attributes, No_Dependence => System.Multiprocessors.Dispatching_Domains);
the new paragraphs:
The usage profile Jorvik 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_CPU_Assignment, No_Dynamic_Priorities, No_Local_Protected_Objects, No_Local_Timing_Events, No_Protected_Type_Allocators, No_Requeue_Statements, No_Select_Statements, No_Specific_Termination_Handlers, No_Task_Allocators, No_Task_Hierarchy, No_Task_Termination, Pure_Barriers, Max_Task_Entries => 0, No_Dependence => Ada.Asynchronous_Task_Control, No_Dependence => Ada.Execution_Time.Group_Budgets, No_Dependence => Ada.Execution_Time.Timers, No_Dependence => Ada.Task_Attributes, No_Dependence => System.Multiprocessors.Dispatching_Domains);
!corrigendum D.13(9/3)
Replace the paragraph:
On a multiprocessor system, an implementation should support a fully partitioned approach. Each processor should have separate and disjoint ready queues.
by:
On a multiprocessor system, an implementation should support a fully partitioned approach if one of these profiles is specified. Each processor should have separate and disjoint ready queues.
!corrigendum D.13(10/3)
Replace the paragraph:
NOTES
42 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.
by:
NOTES
42 For the Ravenscar profile, the effect of the restriction Max_Entry_Queue_Length => 1 applies only to protected entry queues due to the accompanying restriction Max_Task_Entries => 0. The restriction Max_Entry_Queue_Length is not applied by the Jorvik profile.
!corrigendum D.13(11/4)
Replace the paragraph:
43 When the Ravenscar profile is in effect (via the effect of the No_Dynamic_CPU_Assignment restriction), all of the tasks in the partition will execute on a single CPU unless the programmer explicitly uses aspect CPU to specify the CPU assignments for tasks. The use of multiple CPUs requires care, as many guarantees of single CPU scheduling no longer apply.
by:
43 When the Ravenscar or Jorvik profile is in effect (via the effect of the No_Dynamic_CPU_Assignment restriction), all of the tasks in the partition will execute on a single CPU unless the programmer explicitly uses aspect CPU to specify the CPU assignments for tasks. The use of multiple CPUs requires care, as many guarantees of single CPU scheduling no longer apply.
!corrigendum D.13(12/4)
Replace the paragraph:
44 It is not recommended to specify the CPU of a task to be Not_A_Specific_CPU when the Ravenscar profile is in effect. How a partition executes strongly depends on the assignment of tasks to CPUs.
by:
44 It is not recommended to specify the CPU of a task to be Not_A_Specific_CPU when the Ravenscar or Jorvik profile is in effect. How a partition executes strongly depends on the assignment of tasks to CPUs.
45 Any unit that meets the requirements of the Ravenscar profile also meets the requirements of the Jorvik profile.
!ASIS
[Not sure. It seems like some new capabilities might be needed, but I didn't check - Editor.]
!ACATS test
ACATS B- and C-Tests are needed to check that the new profile is supported and enforced.
!appendix

!topic new tasking profile for real-time/embedded applications
!reference Ada 2012 D.13
!from Pat Rogers, Steve Baird 18-07-19
!keywords profile, Ravenscar, real-time/embedded applications

[This is version /01 of the AI - Editor.]

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

From: Randy Brukardt
Sent: Thursday, October 11, 2018  8:32 PM

A couple of wording notes and questions on the original submission:

(1) I take it that the Ravenscar definition itself is unchanged. There ought 
to be some sort of editor's note to that effect in the !wording so that 
readers aren't left wondering (along with your editor, who has to figure out
detailed and individual replacements for each existing paragraph).

(2) You have the "usage profile" paragraph under Syntax, but the existing rule
is under Legality Rules. I changed this since I presume there was no intent to
change this. I also removed headers with no text under them (they're an 
artifact of the paragraph numbering mechanism, in that deleted paragraphs 
remain with text stating that they're deleted -- which keeps the old header 
around).

(3) There is the following after the definition of Jorvik:

Note: Any unit that meets the requirements of the Ravenscar profile also 
meets the requirements of the Yorvik profile.

It's not clear if this is an AARM note (which can go here, and should then be 
clearly marked as an AARM note), or a user note, which has to go at the end 
under "NOTES". It seemed useful to normal readers to me, so I moved it to the
regular notes.

(4) I split the original "discussion" to make a "!problem" and "!proposal". 
The first 2 1/2 paragraphs clearly were describing the problem, and the rest
the solution, so this just required a few extra words.

(5) I fixed "a separate AI" in a couple of places to actually refer to 
AI12-0290-1.

Anyway, I used my best guess for each of these.

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

!topic [Yorvik]{Jorvik}
!topic misspelt
!reference Ada 202x RMD.13(13)
!from Simon Wright 20-09-06
!discussion
Should we include a pronunciation guide (e.g. in (4))?

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

From: Christoph Grein
Sent: Monday, September 7, 2020  4:09 AM

> !discussion
> Should we include a pronunciation guide (e.g. in (4))?

This has been proposed by me long ago and is in D.13(6.b/5).

Alas, this is only in the AARM, so mispronunciations will not easily be 
prevented.

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


Questions? Ask the ACAA Technical Agent