Version 1.1 of 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