!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 WG9 Approved 22-06-22 !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) @drepl This subclause defines the Ravenscar profile. @dby This subclause defines the Ravenscar and Jorvik profiles. !corrigendum D.13(4/3) @drepl The @i@fa Ravenscar is a usage profile (see 13.12). For usage profile Ravenscar, there shall be no @i@fas. @dby The @i@fa Ravenscar and @i@fa Jorvik are usage profiles (see 13.12). For usage profiles Ravenscar and Jorvik, there shall be no @i@fas. !corrigendum D.13(6/4) @dinsa @xcode<@b Task_Dispatching_Policy (FIFO_Within_Priorities); @b Locking_Policy (Ceiling_Locking); @b Detect_Blocking; @b 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);> @dinss The usage profile Jorvik is equivalent to the following set of pragmas: @xcode<@b Task_Dispatching_Policy (FIFO_Within_Priorities); @b Locking_Policy (Ceiling_Locking); @b Detect_Blocking; @b 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) @drepl On a multiprocessor system, an implementation should support a fully partitioned approach. Each processor should have separate and disjoint ready queues. @dby 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) @drepl @xindent<@s9 1 restriction applies only to protected entry queues due to the accompanying restriction of Max_Task_Entries =@> 0.>> @dby @xindent<@s9 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) @drepl @xindent<@s9> @dby @xindent<@s9> !corrigendum D.13(12/4) @drepl @xindent<@s9> @dby @xindent<@s9> @xindent<@s9> !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. ****************************************************************