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

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

!standard D.13(0)          18-10-11 AI12-0291-1/01
!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 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 theses 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 electro-mechanical relay may have a requirement that it not be actuated more than N times per second in order to prevent burn-out. 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 Max_Entry_Queue_Length Simple_Barriers Max_Protected_Entries 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);
Implementation Advice
On a multiprocessor system, an implementation should support a fully partitioned approach if either 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 Yorvik profile.
!discussion
** TBD.
!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 capabilities are supported.
!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.

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


Questions? Ask the ACAA Technical Agent