Annex D
(normative)
Real-Time Systems
1 This Annex specifies additional characteristics of Ada implementations
intended for real-time systems software. To conform to this Annex, an
implementation shall also conform to the Systems Programming Annex.
Metrics
2 The metrics are documentation requirements; an implementation shall
document the values of the language-defined metrics for at least one
configuration of hardware or an underlying system supported by the
implementation, and shall document the details of that configuration.
3 The metrics do not necessarily yield a simple number. For some, a range is
more suitable, for others a formula dependent on some parameter is
appropriate, and for others, it may be more suitable to break the metric into
several cases. Unless specified otherwise, the metrics in this annex are
expressed in processor clock cycles. For metrics that require documentation of
an upper bound, if there is no upper bound, the implementation shall report
that the metric is unbounded.
NOTES
4 1 The specification of the metrics makes a distinction between upper
bounds and simple execution times. Where something is just specified
as "the execution time of" a piece of code, this leaves one the
freedom to choose a nonpathological case. This kind of metric is of
the form "there exists a program such that the value of the metric is
V". Conversely, the meaning of upper bounds is "there is no program
such that the value of the metric is greater than V". This kind of
metric can only be partially tested, by finding the value of V for one
or more test programs.
5 2 The metrics do not cover the whole language; they are limited to
features that are specified in Annex C, "Systems Programming" and in
this Annex. The metrics are intended to provide guidance to potential
users as to whether a particular implementation of such a feature is
going to be adequate for a particular real-time application. As such,
the metrics are aimed at known implementation choices that can result
in significant performance differences.
6 3 The purpose of the metrics is not necessarily to provide
fine-grained quantitative results or to serve as a comparison between
different implementations on the same or different platforms. Instead,
their goal is rather qualitative; to define a standard set of
approximate values that can be measured and used to estimate the
general suitability of an implementation, or to evaluate the
comparative utility of certain features of an implementation for a
particular real-time application.
D.1 Task Priorities
1/3 This subclause specifies the priority model for real-time systems. In
addition, the methods for specifying priorities are defined.
Paragraphs 2 through 6 were moved to Annex J, "Obsolescent Features".
Static Semantics
6.1/3 For a task type (including the anonymous type of a
single_task_declaration), protected type (including the anonymous type of a
single_protected_declaration), or subprogram, the following language-defined
representation aspects may be specified:
6.2/3 Priority The aspect Priority is an expression, which shall be of type
Integer.
6.3/3 Interrupt_Priority
The aspect Interrupt_Priority is an expression, which shall be
of type Integer.
Legality Rules
7/3 This paragraph was deleted.
8/3 If the Priority aspect is specified for a subprogram, the expression shall
be static, and its value shall be in the range of System.Priority.
8.1/3 At most one of the Priority and Interrupt_Priority aspects may be
specified for a given entity.
8.2/3 Neither of the Priority or Interrupt_Priority aspects shall be specified
for a synchronized interface type.
Static Semantics
9 The following declarations exist in package System:
10 subtype Any_Priority is Integer range implementation-defined;
subtype Priority is Any_Priority
range Any_Priority'First .. implementation-defined;
subtype Interrupt_Priority is Any_Priority
range Priority'Last+1 .. Any_Priority'Last;
11 Default_Priority : constant Priority := (Priority'First + Priority'Last)/2;
12 The full range of priority values supported by an implementation is
specified by the subtype Any_Priority. The subrange of priority values that
are high enough to require the blocking of one or more interrupts is specified
by the subtype Interrupt_Priority. The subrange of priority values below
System.Interrupt_Priority'First is specified by the subtype System.Priority.
13/3 This paragraph was deleted.
Dynamic Semantics
14/3 The Priority aspect has no effect if it is specified for a subprogram
other than the main subprogram; the Priority value is not associated with any
task.
15 A task priority is an integer value that indicates a degree of urgency and
is the basis for resolving competing demands of tasks for resources. Unless
otherwise specified, whenever tasks compete for processors or other
implementation-defined resources, the resources are allocated to the task with
the highest priority value. The base priority of a task is the priority with
which it was created, or to which it was later set by
Dynamic_Priorities.Set_Priority (see D.5). At all times, a task also has an
active priority, which generally reflects its base priority as well as any
priority it inherits from other sources. Priority inheritance is the process
by which the priority of a task or other entity (e.g. a protected object; see
D.3) is used in the evaluation of another task's active priority.
16/3 The effect of specifying a Priority or Interrupt_Priority aspect for a
protected type or single_protected_declaration is discussed in D.3.
17/4 The expression specified for the Priority or Interrupt_Priority aspect of
a task type is evaluated each time an object of the task type is created (see
9.1). For the Priority aspect, the value of the expression is converted to the
subtype Priority; for the Interrupt_Priority aspect, this value is converted
to the subtype Any_Priority. The priority value is then associated with the
task object.
18/3 Likewise, the priority value is associated with the environment task if
the aspect is specified for the main subprogram.
19/3 The initial value of a task's base priority is specified by default or by
means of a Priority or Interrupt_Priority aspect. After a task is created, its
base priority can be changed only by a call to Dynamic_Priorities.Set_Priority
(see D.5). The initial base priority of a task in the absence of an aspect is
the base priority of the task that creates it at the time of creation (see
9.1). If the aspect Priority is not specified for the main subprogram, the
initial base priority of the environment task is System.Default_Priority. The
task's active priority is used when the task competes for processors.
Similarly, the task's active priority is used to determine the task's position
in any queue when Priority_Queuing is specified (see D.4).
20/2 At any time, the active priority of a task is the maximum of all the
priorities the task is inheriting at that instant. For a task that is not held
(see D.11), its base priority is a source of priority inheritance unless
otherwise specified for a particular task dispatching policy. Other sources of
priority inheritance are specified under the following conditions:
21/1 * During activation, a task being activated inherits the active
priority that its activator (see 9.2) had at the time the activation
was initiated.
22/1 * During rendezvous, the task accepting the entry call inherits the
priority of the entry call (see 9.5.3 and D.4).
23 * During a protected action on a protected object, a task inherits the
ceiling priority of the protected object (see 9.5 and D.3).
24 In all of these cases, the priority ceases to be inherited as soon as the
condition calling for the inheritance no longer exists.
Implementation Requirements
25 The range of System.Interrupt_Priority shall include at least one value.
26 The range of System.Priority shall include at least 30 values.
NOTES
27 4 The priority expression can include references to discriminants of
the enclosing type.
28 5 It is a consequence of the active priority rules that at the point
when a task stops inheriting a priority from another source, its
active priority is re-evaluated. This is in addition to other
instances described in this Annex for such re-evaluation.
29/3 6 An implementation may provide a nonstandard mode in which tasks
inherit priorities under conditions other than those specified above.
D.2 Priority Scheduling
1/3 This subclause describes the rules that determine which task is selected
for execution when more than one task is ready (see 9).
D.2.1 The Task Dispatching Model
1/2 The task dispatching model specifies task scheduling, based on conceptual
priority-ordered ready queues.
Static Semantics
1.1/2 The following language-defined library package exists:
1.2/3 package Ada.Dispatching is
pragma Preelaborate(Dispatching);
1.3/3 procedure Yield;
1.4/3 Dispatching_Policy_Error : exception;
end Ada.Dispatching;
1.5/2 Dispatching serves as the parent of other language-defined library units
concerned with task dispatching.
Dynamic Semantics
2/2 A task can become a running task only if it is ready (see 9) and the
execution resources required by that task are available. Processors are
allocated to tasks based on each task's active priority.
3 It is implementation defined whether, on a multiprocessor, a task that is
waiting for access to a protected object keeps its processor busy.
4/2 Task dispatching is the process by which one ready task is selected for
execution on a processor. This selection is done at certain points during the
execution of a task called task dispatching points. A task reaches a task
dispatching point whenever it becomes blocked, and when it terminates. Other
task dispatching points are defined throughout this Annex for specific
policies.
5/2 Task dispatching policies are specified in terms of conceptual ready
queues and task states. A ready queue is an ordered list of ready tasks. The
first position in a queue is called the head of the queue, and the last
position is called the tail of the queue. A task is ready if it is in a ready
queue, or if it is running. Each processor has one ready queue for each
priority value. At any instant, each ready queue of a processor contains
exactly the set of tasks of that priority that are ready for execution on that
processor, but are not running on any processor; that is, those tasks that are
ready, are not running on any processor, and can be executed using that
processor and other available resources. A task can be on the ready queues of
more than one processor.
6/2 Each processor also has one running task, which is the task currently
being executed by that processor. Whenever a task running on a processor
reaches a task dispatching point it goes back to one or more ready queues; a
task (possibly the same task) is then selected to run on that processor. The
task selected is the one at the head of the highest priority nonempty ready
queue; this task is then removed from all ready queues to which it belongs.
7/3 A call of Yield is a task dispatching point. Yield is a potentially
blocking operation (see 9.5.1).
8/2 This paragraph was deleted.
Implementation Permissions
9/2 An implementation is allowed to define additional resources as execution
resources, and to define the corresponding allocation policies for them. Such
resources may have an implementation-defined effect on task dispatching.
10 An implementation may place implementation-defined restrictions on tasks
whose active priority is in the Interrupt_Priority range.
10.1/2 For optimization purposes, an implementation may alter the points at
which task dispatching occurs, in an implementation-defined manner. However, a
delay_statement always corresponds to at least one task dispatching point.
NOTES
11/3 7 Clause 9 specifies under which circumstances a task becomes ready.
The ready state is affected by the rules for task activation and
termination, delay statements, and entry calls. When a task is not
ready, it is said to be blocked.
12 8 An example of a possible implementation-defined execution resource
is a page of physical memory, which needs to be loaded with a
particular page of virtual memory before a task can continue execution.
13 9 The ready queues are purely conceptual; there is no requirement
that such lists physically exist in an implementation.
14 10 While a task is running, it is not on any ready queue. Any time
the task that is running on a processor is added to a ready queue, a
new running task is selected for that processor.
15 11 In a multiprocessor system, a task can be on the ready queues of
more than one processor. At the extreme, if several processors share
the same set of ready tasks, the contents of their ready queues is
identical, and so they can be viewed as sharing one ready queue, and
can be implemented that way. Thus, the dispatching model covers
multiprocessors where dispatching is implemented using a single ready
queue, as well as those with separate dispatching domains.
16 12 The priority of a task is determined by rules specified in this
subclause, and under D.1, "Task Priorities", D.3, "
Priority Ceiling Locking", and D.5, "Dynamic Priorities".
17/2 13 The setting of a task's base priority as a result of a call to
Set_Priority does not always take effect immediately when Set_Priority
is called. The effect of setting the task's base priority is deferred
while the affected task performs a protected action.
D.2.2 Task Dispatching Pragmas
1/3 This subclause allows a single task dispatching policy to be defined for
all priorities, or the range of priorities to be split into subranges that are
assigned individual dispatching policies.
Syntax
2 The form of a pragma Task_Dispatching_Policy is as follows:
3 pragma Task_Dispatching_Policy(policy_identifier);
3.1/2 The form of a pragma Priority_Specific_Dispatching is as follows:
3.2/2 pragma Priority_Specific_Dispatching (
policy_identifier, first_priority_expression,
last_priority_expression);
Name Resolution Rules
3.3/2 The expected type for first_priority_expression and
last_priority_expression is Integer.
Legality Rules
4/2 The policy_identifier used in a pragma Task_Dispatching_Policy shall be
the name of a task dispatching policy.
4.1/2 The policy_identifier used in a pragma Priority_Specific_Dispatching
shall be the name of a task dispatching policy.
4.2/2 Both first_priority_expression and last_priority_expression shall be
static expressions in the range of System.Any_Priority;
last_priority_expression shall have a value greater than or equal to
first_priority_expression.
Static Semantics
4.3/2 Pragma Task_Dispatching_Policy specifies the single task dispatching
policy.
4.4/2 Pragma Priority_Specific_Dispatching specifies the task dispatching
policy for the specified range of priorities. Tasks with base priorities
within the range of priorities specified in a Priority_Specific_Dispatching
pragma have their active priorities determined according to the specified
dispatching policy. Tasks with active priorities within the range of
priorities specified in a Priority_Specific_Dispatching pragma are dispatched
according to the specified dispatching policy.
4.5/3 If a partition contains one or more Priority_Specific_Dispatching
pragmas, the dispatching policy for priorities not covered by any
Priority_Specific_Dispatching pragmas is FIFO_Within_Priorities.
Post-Compilation Rules
5/2 A Task_Dispatching_Policy pragma is a configuration pragma. A
Priority_Specific_Dispatching pragma is a configuration pragma.
5.1/2 The priority ranges specified in more than one
Priority_Specific_Dispatching pragma within the same partition shall not be
overlapping.
5.2/2 If a partition contains one or more Priority_Specific_Dispatching
pragmas it shall not contain a Task_Dispatching_Policy pragma.
6/2 This paragraph was deleted.
Dynamic Semantics
7/2 A task dispatching policy specifies the details of task dispatching that
are not covered by the basic task dispatching model. These rules govern when
tasks are inserted into and deleted from the ready queues. A single task
dispatching policy is specified by a Task_Dispatching_Policy pragma. Pragma
Priority_Specific_Dispatching assigns distinct dispatching policies to
subranges of System.Any_Priority.
7.1/2 If neither pragma applies to any of the program units comprising a
partition, the task dispatching policy for that partition is unspecified.
7.2/3 If a partition contains one or more Priority_Specific_Dispatching
pragmas, a task dispatching point occurs for the currently running task of a
processor whenever there is a nonempty ready queue for that processor with a
higher priority than the priority of the running task.
7.3/2 A task that has its base priority changed may move from one dispatching
policy to another. It is immediately subject to the new dispatching policy.
Paragraphs 7 through 13 were moved to D.2.3.
Implementation Requirements
14.1/2 An implementation shall allow, for a single partition, both the locking
policy (see D.3) to be specified as Ceiling_Locking and also one or more
Priority_Specific_Dispatching pragmas to be given.
Documentation Requirements
Paragraphs 14 through 16 were moved to D.2.3.
Implementation Permissions
18/2 Implementations are allowed to define other task dispatching policies,
but need not support more than one task dispatching policy per partition.
19/2 An implementation need not support pragma Priority_Specific_Dispatching
if it is infeasible to support it in the target environment.
NOTES
Paragraphs 19 through 21 were deleted.
D.2.3 Preemptive Dispatching
1/3 This subclause defines a preemptive task dispatching policy.
Static Semantics
2/2 The policy_identifier FIFO_Within_Priorities is a task dispatching policy.
Dynamic Semantics
3/2 When FIFO_Within_Priorities is in effect, modifications to the ready
queues occur only as follows:
4/2 * When a blocked task becomes ready, it is added at the tail of the
ready queue for its active priority.
5/2 * When the active priority of a ready task that is not running changes,
or the setting of its base priority takes effect, the task is removed
from the ready queue for its old active priority and is added at the
tail of the ready queue for its new active priority, except in the
case where the active priority is lowered due to the loss of inherited
priority, in which case the task is added at the head of the ready
queue for its new active priority.
6/2 * When the setting of the base priority of a running task takes effect,
the task is added to the tail of the ready queue for its active
priority.
7/2 * When a task executes a delay_statement that does not result in
blocking, it is added to the tail of the ready queue for its active
priority.
8/2 Each of the events specified above is a task dispatching point (see
D.2.1).
9/2 A task dispatching point occurs for the currently running task of a
processor whenever there is a nonempty ready queue for that processor with a
higher priority than the priority of the running task. The currently running
task is said to be preempted and it is added at the head of the ready queue
for its active priority.
Implementation Requirements
10/2 An implementation shall allow, for a single partition, both the task
dispatching policy to be specified as FIFO_Within_Priorities and also the
locking policy (see D.3) to be specified as Ceiling_Locking.
Documentation Requirements
11/2 Priority inversion is the duration for which a task remains at the head
of the highest priority nonempty ready queue while the processor executes a
lower priority task. The implementation shall document:
12/2 * The maximum priority inversion a user task can experience due to
activity of the implementation (on behalf of lower priority tasks),
and
13/2 * whether execution of a task can be preempted by the implementation
processing of delay expirations for lower priority tasks, and if so,
for how long.
NOTES
14/2 14 If the active priority of a running task is lowered due to loss of
inherited priority (as it is on completion of a protected operation)
and there is a ready task of the same active priority that is not
running, the running task continues to run (provided that there is no
higher priority task).
15/2 15 Setting the base priority of a ready task causes the task to move
to the tail of the queue for its active priority, regardless of
whether the active priority of the task actually changes.
D.2.4 Non-Preemptive Dispatching
1/3 This subclause defines a non-preemptive task dispatching policy.
Static Semantics
2/2 The policy_identifier Non_Preemptive_FIFO_Within_Priorities is a task
dispatching policy.
2.1/3 The following language-defined library package exists:
2.2/3 package Ada.Dispatching.Non_Preemptive is
pragma Preelaborate(Non_Preemptive);
procedure Yield_To_Higher;
procedure Yield_To_Same_Or_Higher renames Yield;
end Ada.Dispatching.Non_Preemptive;
2.3/3 A call of Yield_To_Higher is a task dispatching point for this policy.
If the task at the head of the highest priority ready queue has a higher
active priority than the calling task, then the calling task is preempted.
Legality Rules
3/2 Non_Preemptive_FIFO_Within_Priorities shall not be specified as the
policy_identifier of pragma Priority_Specific_Dispatching (see D.2.2).
Dynamic Semantics
4/2 When Non_Preemptive_FIFO_Within_Priorities is in effect, modifications to
the ready queues occur only as follows:
5/2 * When a blocked task becomes ready, it is added at the tail of the
ready queue for its active priority.
6/2 * When the active priority of a ready task that is not running changes,
or the setting of its base priority takes effect, the task is removed
from the ready queue for its old active priority and is added at the
tail of the ready queue for its new active priority.
7/2 * When the setting of the base priority of a running task takes effect,
the task is added to the tail of the ready queue for its active
priority.
8/2 * When a task executes a delay_statement that does not result in
blocking, it is added to the tail of the ready queue for its active
priority.
9/3 For this policy, blocking or termination of a task, a delay_statement, a
call to Yield_To_Higher, and a call to Yield_To_Same_Or_Higher or Yield are
the only task dispatching points (see D.2.1).
Implementation Requirements
10/2 An implementation shall allow, for a single partition, both the task
dispatching policy to be specified as Non_Preemptive_FIFO_Within_Priorities
and also the locking policy (see D.3) to be specified as Ceiling_Locking.
Implementation Permissions
11/3 Since implementations are allowed to round all ceiling priorities in
subrange System.Priority to System.Priority'Last (see D.3), an implementation
may allow a task of a partition using the Non_Premptive_FIFO_Within_Priorities
policy to execute within a protected object without raising its active
priority provided the associated protected unit does not contain any
subprograms with aspects Interrupt_Handler or Attach_Handler specified, nor
does the unit have aspect Interrupt_Priority specified. When the locking
policy (see D.3) is Ceiling_Locking, an implementation taking advantage of
this permission shall ensure that a call to Yield_to_Higher that occurs within
a protected action uses the ceiling priority of the protected object (rather
than the active priority of the task) when determining whether to preempt the
task.
D.2.5 Round Robin Dispatching
1/3 This subclause defines the task dispatching policy
Round_Robin_Within_Priorities and the package Round_Robin.
Static Semantics
2/2 The policy_identifier Round_Robin_Within_Priorities is a task dispatching
policy.
3/2 The following language-defined library package exists:
4/2 with System;
with Ada.Real_Time;
package Ada.Dispatching.Round_Robin is
Default_Quantum : constant Ada.Real_Time.Time_Span :=
implementation-defined;
procedure Set_Quantum (Pri : in System.Priority;
Quantum : in Ada.Real_Time.Time_Span);
procedure Set_Quantum (Low, High : in System.Priority;
Quantum : in Ada.Real_Time.Time_Span);
function Actual_Quantum (Pri : System.Priority)
return Ada.Real_Time.Time_Span;
function Is_Round_Robin (Pri : System.Priority) return Boolean;
end Ada.Dispatching.Round_Robin;
5/2 When task dispatching policy Round_Robin_Within_Priorities is the single
policy in effect for a partition, each task with priority in the range of
System.Interrupt_Priority is dispatched according to policy
FIFO_Within_Priorities.
Dynamic Semantics
6/2 The procedures Set_Quantum set the required Quantum value for a single
priority level Pri or a range of priority levels Low .. High. If no quantum is
set for a Round Robin priority level, Default_Quantum is used.
7/2 The function Actual_Quantum returns the actual quantum used by the
implementation for the priority level Pri.
8/3 The function Is_Round_Robin returns True if priority Pri is covered by
task dispatching policy Round_Robin_Within_Priorities; otherwise, it returns
False.
9/2 A call of Actual_Quantum or Set_Quantum raises exception
Dispatching.Dispatching_Policy_Error if a predefined policy other than
Round_Robin_Within_Priorities applies to the specified priority or any of the
priorities in the specified range.
10/2 For Round_Robin_Within_Priorities, the dispatching rules for
FIFO_Within_Priorities apply with the following additional rules:
11/2 * When a task is added or moved to the tail of the ready queue for its
base priority, it has an execution time budget equal to the quantum
for that priority level. This will also occur when a blocked task
becomes executable again.
12/2 * When a task is preempted (by a higher priority task) and is added to
the head of the ready queue for its priority level, it retains its
remaining budget.
13/2 * While a task is executing, its budget is decreased by the amount of
execution time it uses. The accuracy of this accounting is the same as
that for execution time clocks (see D.14).
14/2 * When a task has exhausted its budget and is without an inherited
priority (and is not executing within a protected operation), it is
moved to the tail of the ready queue for its priority level. This is a
task dispatching point.
Implementation Requirements
15/2 An implementation shall allow, for a single partition, both the task
dispatching policy to be specified as Round_Robin_Within_Priorities and also
the locking policy (see D.3) to be specified as Ceiling_Locking.
Documentation Requirements
16/2 An implementation shall document the quantum values supported.
17/2 An implementation shall document the accuracy with which it detects the
exhaustion of the budget of a task.
NOTES
18/2 16 Due to implementation constraints, the quantum value returned by
Actual_Quantum might not be identical to that set with Set_Quantum.
19/2 17 A task that executes continuously with an inherited priority will
not be subject to round robin dispatching.
D.2.6 Earliest Deadline First Dispatching
1/2 The deadline of a task is an indication of the urgency of the task; it
represents a point on an ideal physical time line. The deadline might affect
how resources are allocated to the task.
2/3 This subclause defines a package for representing the deadline of a task
and a dispatching policy that defines Earliest Deadline First (EDF)
dispatching. An aspect is defined to assign an initial deadline to a task.
Paragraphs 3 through 6 were moved to Annex J, "Obsolescent Features".
Static Semantics
7/2 The policy_identifier EDF_Across_Priorities is a task dispatching policy.
8/2 The following language-defined library package exists:
9/2 with Ada.Real_Time;
with Ada.Task_Identification;
package Ada.Dispatching.EDF is
subtype Deadline is Ada.Real_Time.Time;
Default_Deadline : constant Deadline :=
Ada.Real_Time.Time_Last;
procedure Set_Deadline (D : in Deadline;
T : in Ada.Task_Identification.Task_Id :=
Ada.Task_Identification.Current_Task);
procedure Delay_Until_And_Set_Deadline (
Delay_Until_Time : in Ada.Real_Time.Time;
Deadline_Offset : in Ada.Real_Time.Time_Span);
function Get_Deadline (T : Ada.Task_Identification.Task_Id :=
Ada.Task_Identification.Current_Task) return Deadline;
end Ada.Dispatching.EDF;
9.1/3 For a task type (including the anonymous type of a
single_task_declaration) or subprogram, the following language-defined
representation aspect may be specified:
9.2/3 Relative_Deadline
The aspect Relative_Deadline is an expression, which shall be
of type Real_Time.Time_Span.
Legality Rules
9.3/3 The Relative_Deadline aspect shall not be specified on a task interface
type.
Post-Compilation Rules
10/2 If the EDF_Across_Priorities policy is specified for a partition, then
the Ceiling_Locking policy (see D.3) shall also be specified for the partition.
11/2 If the EDF_Across_Priorities policy appears in a
Priority_Specific_Dispatching pragma (see D.2.2) in a partition, then the
Ceiling_Locking policy (see D.3) shall also be specified for the partition.
Dynamic Semantics
12/3 The Relative_Deadline aspect has no effect if it is specified for a
subprogram other than the main subprogram.
13/3 The initial absolute deadline of a task for which aspect
Relative_Deadline is specified is the value of Real_Time.Clock + the
expression that is the value of the aspect, where this entire expression,
including the call of Real_Time.Clock, is evaluated between task creation and
the start of its activation. If the aspect Relative_Deadline is not specified,
then the initial absolute deadline of a task is the value of Default_Deadline.
The environment task is also given an initial deadline by this rule, using the
value of the Relative_Deadline aspect of the main subprogram (if any).
14/2 The procedure Set_Deadline changes the absolute deadline of the task to
D. The function Get_Deadline returns the absolute deadline of the task.
15/2 The procedure Delay_Until_And_Set_Deadline delays the calling task until
time Delay_Until_Time. When the task becomes runnable again it will have
deadline Delay_Until_Time + Deadline_Offset.
16/2 On a system with a single processor, the setting of the deadline of a
task to the new value occurs immediately at the first point that is outside
the execution of a protected action. If the task is currently on a ready queue
it is removed and re-entered on to the ready queue determined by the rules
defined below.
17/2 When EDF_Across_Priorities is specified for priority range Low..High all
ready queues in this range are ordered by deadline. The task at the head of a
queue is the one with the earliest deadline.
18/2 A task dispatching point occurs for the currently running task T to which
policy EDF_Across_Priorities applies:
19/2 * when a change to the deadline of T occurs;
20/2 * there is a task on the ready queue for the active priority of T with
a deadline earlier than the deadline of T; or
21/2 * there is a nonempty ready queue for that processor with a higher
priority than the active priority of the running task.
22/2 In these cases, the currently running task is said to be preempted and is
returned to the ready queue for its active priority.
23/2 For a task T to which policy EDF_Across_Priorities applies, the base
priority is not a source of priority inheritance; the active priority when
first activated or while it is blocked is defined as the maximum of the
following:
24/2 * the lowest priority in the range specified as EDF_Across_Priorities
that includes the base priority of T;
25/2 * the priorities, if any, currently inherited by T;
26/3 * the highest priority P, if any, less than the base priority of T such
that one or more tasks are executing within a protected object with
ceiling priority P and task T has an earlier deadline than all such
tasks; and furthermore T has an earlier deadline than all other tasks
on ready queues with priorities in the given EDF_Across_Priorities
range that are strictly less than P.
27/2 When a task T is first activated or becomes unblocked, it is added to the
ready queue corresponding to this active priority. Until it becomes blocked
again, the active priority of T remains no less than this value; it will
exceed this value only while it is inheriting a higher priority.
28/2 When the setting of the base priority of a ready task takes effect and
the new priority is in a range specified as EDF_Across_Priorities, the task is
added to the ready queue corresponding to its new active priority, as
determined above.
29/2 For all the operations defined in Dispatching.EDF, Tasking_Error is
raised if the task identified by T has terminated. Program_Error is raised if
the value of T is Null_Task_Id.
Bounded (Run-Time) Errors
30/2 If EDF_Across_Priorities is specified for priority range Low..High, it is
a bounded error to declare a protected object with ceiling priority Low or to
assign the value Low to attribute 'Priority. In either case either
Program_Error is raised or the ceiling of the protected object is assigned the
value Low+1.
Erroneous Execution
31/2 If a value of Task_Id is passed as a parameter to any of the subprograms
of this package and the corresponding task object no longer exists, the
execution of the program is erroneous.
Documentation Requirements
32/2 On a multiprocessor, the implementation shall document any conditions
that cause the completion of the setting of the deadline of a task to be
delayed later than what is specified for a single processor.
NOTES
33/3 18 If two adjacent priority ranges, A..B and B+1..C are specified to
have policy EDF_Across_Priorities, then this is not equivalent to this
policy being specified for the single range, A..C.
34/2 19 The above rules implement the preemption-level protocol (also
called Stack Resource Policy protocol) for resource sharing under EDF
dispatching. The preemption-level for a task is denoted by its base
priority. The definition of a ceiling preemption-level for a protected
object follows the existing rules for ceiling locking.
D.3 Priority Ceiling Locking
1/3 This subclause specifies the interactions between priority task scheduling
and protected object ceilings. This interaction is based on the concept of the
ceiling priority of a protected object.
Syntax
2 The form of a pragma Locking_Policy is as follows:
3 pragma Locking_Policy(policy_identifier);
Legality Rules
4 The policy_identifier shall either be Ceiling_Locking or an
implementation-defined identifier.
Post-Compilation Rules
5 A Locking_Policy pragma is a configuration pragma.
Dynamic Semantics
6/2 A locking policy specifies the details of protected object locking. All
protected objects have a priority. The locking policy specifies the meaning of
the priority of a protected object, and the relationships between these
priorities and task priorities. In addition, the policy specifies the state of
a task when it executes a protected action, and how its active priority is
affected by the locking. The locking policy is specified by a Locking_Policy
pragma. For implementation-defined locking policies, the meaning of the
priority of a protected object is implementation defined. If no Locking_Policy
pragma applies to any of the program units comprising a partition, the locking
policy for that partition, as well as the meaning of the priority of a
protected object, are implementation defined.
6.1/3 The expression specified for the Priority or Interrupt_Priority aspect
(see D.1) is evaluated as part of the creation of the corresponding protected
object and converted to the subtype System.Any_Priority or
System.Interrupt_Priority, respectively. The value of the expression is the
initial priority of the corresponding protected object. If no Priority or
Interrupt_Priority aspect is specified for a protected object, the initial
priority is specified by the locking policy.
7 There is one predefined locking policy, Ceiling_Locking; this policy is
defined as follows:
8/3 * Every protected object has a ceiling priority, which is determined by
either a Priority or Interrupt_Priority aspect as defined in D.1, or
by assignment to the Priority attribute as described in D.5.2. The
ceiling priority of a protected object (or ceiling, for short) is an
upper bound on the active priority a task can have when it calls
protected operations of that protected object.
9/2 * The initial ceiling priority of a protected object is equal to the
initial priority for that object.
10/4 * If an Interrupt_Handler or Attach_Handler aspect (see C.3.1) is
specified for a protected subprogram of a protected type that does not
have either the Priority or Interrupt_Priority aspect specified, the
initial priority of protected objects of that type is implementation
defined, but in the range of the subtype System.Interrupt_Priority.
11/3 * If neither aspect Priority nor Interrupt_Priority is specified for a
protected type, and no protected subprogram of the type has aspect
Interrupt_Handler or Attach_Handler specified, then the initial
priority of the corresponding protected object is System.Priority'Last.
12 * While a task executes a protected action, it inherits the ceiling
priority of the corresponding protected object.
13 * When a task calls a protected operation, a check is made that its
active priority is not higher than the ceiling of the corresponding
protected object; Program_Error is raised if this check fails.
Bounded (Run-Time) Errors
13.1/2 Following any change of priority, it is a bounded error for the active
priority of any task with a call queued on an entry of a protected object to
be higher than the ceiling priority of the protected object. In this case one
of the following applies:
13.2/2 * at any time prior to executing the entry body Program_Error is
raised in the calling task;
13.3/2 * when the entry is open the entry body is executed at the ceiling
priority of the protected object;
13.4/2 * when the entry is open the entry body is executed at the ceiling
priority of the protected object and then Program_Error is raised in
the calling task; or
13.5/2 * when the entry is open the entry body is executed at the ceiling
priority of the protected object that was in effect when the entry
call was queued.
Implementation Permissions
14 The implementation is allowed to round all ceilings in a certain subrange
of System.Priority or System.Interrupt_Priority up to the top of that
subrange, uniformly.
15/2 Implementations are allowed to define other locking policies, but need
not support more than one locking policy per partition.
16 Since implementations are allowed to place restrictions on code that runs
at an interrupt-level active priority (see C.3.1 and D.2.1), the
implementation may implement a language feature in terms of a protected object
with an implementation-defined ceiling, but the ceiling shall be no less than
Priority'Last.
Implementation Advice
17 The implementation should use names that end with "_Locking" for
implementation-defined locking policies.
NOTES
18 20 While a task executes in a protected action, it can be preempted
only by tasks whose active priorities are higher than the ceiling
priority of the protected object.
19 21 If a protected object has a ceiling priority in the range of
Interrupt_Priority, certain interrupts are blocked while protected
actions of that object execute. In the extreme, if the ceiling is
Interrupt_Priority'Last, all blockable interrupts are blocked during
that time.
20 22 The ceiling priority of a protected object has to be in the
Interrupt_Priority range if one of its procedures is to be used as an
interrupt handler (see C.3).
21 23 When specifying the ceiling of a protected object, one should
choose a value that is at least as high as the highest active priority
at which tasks can be executing when they call protected operations of
that object. In determining this value the following factors, which
can affect active priority, should be considered: the effect of
Set_Priority, nested protected operations, entry calls, task
activation, and other implementation-defined factors.
22 24 Attaching a protected procedure whose ceiling is below the
interrupt hardware priority to an interrupt causes the execution of
the program to be erroneous (see C.3.1).
23 25 On a single processor implementation, the ceiling priority rules
guarantee that there is no possibility of deadlock involving only
protected subprograms (excluding the case where a protected operation
calls another protected operation on the same protected object).
D.4 Entry Queuing Policies
1/3 This subclause specifies a mechanism for a user to choose an entry queuing
policy. It also defines two such policies. Other policies are implementation
defined.
Syntax
2 The form of a pragma Queuing_Policy is as follows:
3 pragma Queuing_Policy(policy_identifier);
Legality Rules
4 The policy_identifier shall be either FIFO_Queuing, Priority_Queuing or an
implementation-defined identifier.
Post-Compilation Rules
5 A Queuing_Policy pragma is a configuration pragma.
Dynamic Semantics
6 A queuing policy governs the order in which tasks are queued for entry
service, and the order in which different entry queues are considered for
service. The queuing policy is specified by a Queuing_Policy pragma.
7/2 Two queuing policies, FIFO_Queuing and Priority_Queuing, are language
defined. If no Queuing_Policy pragma applies to any of the program units
comprising the partition, the queuing policy for that partition is
FIFO_Queuing. The rules for this policy are specified in 9.5.3 and 9.7.1.
8 The Priority_Queuing policy is defined as follows:
9 * The calls to an entry (including a member of an entry family) are
queued in an order consistent with the priorities of the calls. The
priority of an entry call is initialized from the active priority of
the calling task at the time the call is made, but can change later.
Within the same priority, the order is consistent with the calling (or
requeuing, or priority setting) time (that is, a FIFO order).
10/1 * After a call is first queued, changes to the active priority of a
task do not affect the priority of the call, unless the base priority
of the task is set while the task is blocked on an entry call.
11 * When the base priority of a task is set (see D.5), if the task is
blocked on an entry call, and the call is queued, the priority of the
call is updated to the new active priority of the calling task. This
causes the call to be removed from and then reinserted in the queue at
the new active priority.
12 * When more than one condition of an entry_barrier of a protected object
becomes True, and more than one of the respective queues is nonempty,
the call with the highest priority is selected. If more than one such
call has the same priority, the call that is queued on the entry whose
declaration is first in textual order in the protected_definition is
selected. For members of the same entry family, the one with the lower
family index is selected.
13 * If the expiration time of two or more open delay_alternatives is the
same and no other accept_alternatives are open, the
sequence_of_statements of the delay_alternative that is first in
textual order in the selective_accept is executed.
14 * When more than one alternative of a selective_accept is open and has
queued calls, an alternative whose queue has the highest-priority call
at its head is selected. If two or more open alternatives have
equal-priority queued calls, then a call on the entry in the
accept_alternative that is first in textual order in the
selective_accept is selected.
Implementation Permissions
15/2 Implementations are allowed to define other queuing policies, but need
not support more than one queuing policy per partition.
15.1/2 Implementations are allowed to defer the reordering of entry queues
following a change of base priority of a task blocked on the entry call if it
is not practical to reorder the queue immediately.
Implementation Advice
16 The implementation should use names that end with "_Queuing" for
implementation-defined queuing policies.
D.5 Dynamic Priorities
1/3 This subclause describes how the priority of an entity can be modified or
queried at run time.
D.5.1 Dynamic Priorities for Tasks
1/3 This subclause describes how the base priority of a task can be modified
or queried at run time.
Static Semantics
2 The following language-defined library package exists:
3/2 with System;
with Ada.Task_Identification; -- See C.7.1
package Ada.Dynamic_Priorities is
pragma Preelaborate(Dynamic_Priorities);
4 procedure Set_Priority(Priority : in System.Any_Priority;
T : in Ada.Task_Identification.Task_Id :=
Ada.Task_Identification.Current_Task);
5 function Get_Priority (T : Ada.Task_Identification.Task_Id :=
Ada.Task_Identification.Current_Task)
return System.Any_Priority;
6 end Ada.Dynamic_Priorities;
Dynamic Semantics
7 The procedure Set_Priority sets the base priority of the specified task to
the specified Priority value. Set_Priority has no effect if the task is
terminated.
8 The function Get_Priority returns T's current base priority. Tasking_Error
is raised if the task is terminated.
9 Program_Error is raised by Set_Priority and Get_Priority if T is equal to
Null_Task_Id.
10/2 On a system with a single processor, the setting of the base priority of
a task T to the new value occurs immediately at the first point when T is
outside the execution of a protected action.
Paragraph 11 was deleted.
Erroneous Execution
12 If any subprogram in this package is called with a parameter T that
specifies a task object that no longer exists, the execution of the program is
erroneous.
Documentation Requirements
12.1/2 On a multiprocessor, the implementation shall document any conditions
that cause the completion of the setting of the priority of a task to be
delayed later than what is specified for a single processor.
Metrics
13 The implementation shall document the following metric:
14 * The execution time of a call to Set_Priority, for the nonpreempting
case, in processor clock cycles. This is measured for a call that
modifies the priority of a ready task that is not running (which
cannot be the calling one), where the new base priority of the
affected task is lower than the active priority of the calling task,
and the affected task is not on any entry queue and is not executing a
protected operation.
NOTES
15/2 26 Setting a task's base priority affects task dispatching. First, it
can change the task's active priority. Second, under the
FIFO_Within_Priorities policy it always causes the task to move to the
tail of the ready queue corresponding to its active priority, even if
the new base priority is unchanged.
16 27 Under the priority queuing policy, setting a task's base priority
has an effect on a queued entry call if the task is blocked waiting
for the call. That is, setting the base priority of a task causes the
priority of a queued entry call from that task to be updated and the
call to be removed and then reinserted in the entry queue at the new
priority (see D.4), unless the call originated from the
triggering_statement of an asynchronous_select.
17 28 The effect of two or more Set_Priority calls executed in parallel
on the same task is defined as executing these calls in some serial
order.
18/3 29 The rule for when Tasking_Error is raised for Set_Priority or
Get_Priority is different from the rule for when Tasking_Error is
raised on an entry call (see 9.5.3). In particular, querying the
priority of a completed or an abnormal task is allowed, so long as the
task is not yet terminated, and setting the priority of a task is
allowed for any task state (including for terminated tasks).
19 30 Changing the priorities of a set of tasks can be performed by a
series of calls to Set_Priority for each task separately. For this to
work reliably, it should be done within a protected operation that has
high enough ceiling priority to guarantee that the operation completes
without being preempted by any of the affected tasks.
D.5.2 Dynamic Priorities for Protected Objects
1/3 This subclause specifies how the priority of a protected object can be
modified or queried at run time.
Static Semantics
2/2 The following attribute is defined for a prefix P that denotes a protected
object:
3/2 P'Priority Denotes a non-aliased component of the protected object P.
This component is of type System.Any_Priority and its value is
the priority of P. P'Priority denotes a variable if and only
if P denotes a variable. A reference to this attribute shall
appear only within the body of P.
4/2 The initial value of this attribute is the initial value of the priority
of the protected object, and can be changed by an assignment.
Dynamic Semantics
5/3 If the locking policy Ceiling_Locking (see D.3) is in effect, then the
ceiling priority of a protected object P is set to the value of P'Priority at
the end of each protected action of P.
6/3 If the locking policy Ceiling_Locking is in effect, then for a protected
object P with either an Attach_Handler or Interrupt_Handler aspect specified
for one of its procedures, a check is made that the value to be assigned to
P'Priority is in the range System.Interrupt_Priority. If the check fails,
Program_Error is raised.
Metrics
7/2 The implementation shall document the following metric:
8/2 * The difference in execution time of calls to the following procedures
in protected object P:
9/2 protected P is
procedure Do_Not_Set_Ceiling (Pr : System.Any_Priority);
procedure Set_Ceiling (Pr : System.Any_Priority);
end P;
10/2 protected body P is
procedure Do_Not_Set_Ceiling (Pr : System.Any_Priority) is
begin
null;
end;
procedure Set_Ceiling (Pr : System.Any_Priority) is
begin
P'Priority := Pr;
end;
end P;
NOTES
11/2 31 Since P'Priority is a normal variable, the value following an
assignment to the attribute immediately reflects the new value even
though its impact on the ceiling priority of P is postponed until
completion of the protected action in which it is executed.
D.6 Preemptive Abort
1/3 This subclause specifies requirements on the immediacy with which an
aborted construct is completed.
Dynamic Semantics
2 On a system with a single processor, an aborted construct is completed
immediately at the first point that is outside the execution of an
abort-deferred operation.
Documentation Requirements
3 On a multiprocessor, the implementation shall document any conditions that
cause the completion of an aborted construct to be delayed later than what is
specified for a single processor.
Metrics
4 The implementation shall document the following metrics:
5 * The execution time, in processor clock cycles, that it takes for an
abort_statement to cause the completion of the aborted task. This is
measured in a situation where a task T2 preempts task T1 and aborts
T1. T1 does not have any finalization code. T2 shall verify that T1
has terminated, by means of the Terminated attribute.
6 * On a multiprocessor, an upper bound in seconds, on the time that the
completion of an aborted task can be delayed beyond the point that it
is required for a single processor.
7/2 * An upper bound on the execution time of an asynchronous_select, in
processor clock cycles. This is measured between a point immediately
before a task T1 executes a protected operation Pr.Set that makes the
condition of an entry_barrier Pr.Wait True, and the point where task
T2 resumes execution immediately after an entry call to Pr.Wait in an
asynchronous_select. T1 preempts T2 while T2 is executing the
abortable part, and then blocks itself so that T2 can execute. The
execution time of T1 is measured separately, and subtracted.
8 * An upper bound on the execution time of an asynchronous_select, in the
case that no asynchronous transfer of control takes place. This is
measured between a point immediately before a task executes the
asynchronous_select with a nonnull abortable part, and the point where
the task continues execution immediately after it. The execution time
of the abortable part is subtracted.
Implementation Advice
9 Even though the abort_statement is included in the list of potentially
blocking operations (see 9.5.1), it is recommended that this statement be
implemented in a way that never requires the task executing the
abort_statement to block.
10 On a multi-processor, the delay associated with aborting a task on another
processor should be bounded; the implementation should use periodic polling,
if necessary, to achieve this.
NOTES
11 32 Abortion does not change the active or base priority of the
aborted task.
12 33 Abortion cannot be more immediate than is allowed by the rules for
deferral of abortion during finalization and in protected actions.
D.7 Tasking Restrictions
1/3 This subclause defines restrictions that can be used with a pragma
Restrictions (see 13.12) to facilitate the construction of highly efficient
tasking run-time systems.
Static Semantics
2 The following restriction_identifiers are language defined:
3/3 No_Task_Hierarchy
No task depends on a master other than the library-level
master.
4/3 No_Nested_Finalization
Objects of a type that needs finalization (see 7.6) are
declared only at library level. If an access type does not
have library-level accessibility, then there are no
allocators of the type where the type determined by the
subtype_mark of the subtype_indication or
qualified_expression needs finalization.
5/3 No_Abort_Statements
There are no abort_statements, and there is no use of a name
denoting Task_Identification.Abort_Task.
6 No_Terminate_Alternatives
There are no selective_accepts with terminate_alternatives.
7 No_Task_Allocators
There are no allocators for task types or types containing
task subcomponents.
7.1/3 In the case of an initialized allocator of an access type
whose designated type is class-wide and limited, a check is
made that the specific type of the allocated object has no
task subcomponents. Program_Error is raised if this check
fails.
8 No_Implicit_Heap_Allocations
There are no operations that implicitly require heap storage
allocation to be performed by the implementation. The
operations that implicitly require heap storage allocation are
implementation defined.
9/2 No_Dynamic_Priorities
There are no semantic dependences on the package
Dynamic_Priorities, and no occurrences of the attribute
Priority.
10/3 No_Dynamic_Attachment
There is no use of a name denoting any of the operations
defined in package Interrupts (Is_Reserved, Is_Attached,
Current_Handler, Attach_Handler, Exchange_Handler,
Detach_Handler, and Reference).
10.1/4 No_Dynamic_CPU_Assignment
No task has the CPU aspect specified to be a non-static
expression. Each task (including the environment task) that
has the CPU aspect specified as Not_A_Specific_CPU will be
assigned to a particular implementation-defined CPU. The same
is true for the environment task when the CPU aspect is not
specified. Any other task without a CPU aspect will activate
and execute on the same processor as its activating task.
10.2/3 No_Local_Protected_Objects
Protected objects are declared only at library level.
10.3/3 No_Local_Timing_Events
Timing_Events are declared only at library level.
10.4/2 No_Protected_Type_Allocators
There are no allocators for protected types or types
containing protected type subcomponents.
10.5/3 In the case of an initialized allocator of an access type
whose designated type is class-wide and limited, a check is
made that the specific type of the allocated object has no
protected subcomponents. Program_Error is raised if this check
fails.
10.6/3 No_Relative_Delay
There are no delay_relative_statements, and there is no use of
a name that denotes the Timing_Events.Set_Handler subprogram
that has a Time_Span parameter.
10.7/3 No_Requeue_Statements
There are no requeue_statements.
10.8/3 No_Select_Statements
There are no select_statements.
10.9/3 No_Specific_Termination_Handlers
There is no use of a name denoting the Set_Specific_Handler
and Specific_Handler subprograms in Task_Termination.
10.10/4 No_Tasks_Unassigned_To_CPU
The CPU aspect is specified for the environment task. No CPU
aspect is specified to be statically equal to
Not_A_Specific_CPU. If aspect CPU is specified (dynamically)
to the value Not_A_Specific_CPU, then Program_Error is raised.
If Set_CPU or Delay_Until_And_Set_CPU are called with the CPU
parameter equal to Not_A_Specific_CPU, then Program_Error is
raised.
10.11/3 Simple_Barriers
The Boolean expression in each entry barrier is either a
static expression or a name that statically denotes a
component of the enclosing protected object.
11 The following restriction_parameter_identifiers are language defined:
12 Max_Select_Alternatives
Specifies the maximum number of alternatives in a
selective_accept.
13 Max_Task_Entries
Specifies the maximum number of entries per task. The bounds
of every entry family of a task unit shall be static, or shall
be defined by a discriminant of a subtype whose corresponding
bound is static. A value of zero indicates that no rendezvous
are possible.
14 Max_Protected_Entries
Specifies the maximum number of entries per protected type.
The bounds of every entry family of a protected unit shall be
static, or shall be defined by a discriminant of a subtype
whose corresponding bound is static.
Dynamic Semantics
15/2 The following restriction_identifier is language defined:
15.1/2 No_Task_Termination
All tasks are nonterminating. It is implementation-defined
what happens if a task attempts to terminate. If there is a
fall-back handler (see C.7.3) set for the partition it should
be called when the first task attempts to terminate.
16 The following restriction_parameter_identifiers are language defined:
17/1 Max_Storage_At_Blocking
Specifies the maximum portion (in storage elements) of a
task's Storage_Size that can be retained by a blocked task. If
an implementation chooses to detect a violation of this
restriction, Storage_Error should be raised; otherwise, the
behavior is implementation defined.
18/1 Max_Asynchronous_Select_Nesting
Specifies the maximum dynamic nesting level of
asynchronous_selects. A value of zero prevents the use of any
asynchronous_select and, if a program contains an asynchronous_-
select, it is illegal. If an implementation chooses to detect
a violation of this restriction for values other than zero,
Storage_Error should be raised; otherwise, the behavior is
implementation defined.
19/1 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.
19.1/2 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 or requeue.
19.2/3 No_Standard_Allocators_After_Elaboration
Specifies that an allocator using a standard storage pool (see
13.11) shall not occur within a parameterless library
subprogram, nor within the handled_sequence_of_statements of a
task body. For the purposes of this rule, an allocator of a
type derived from a formal access type does not use a standard
storage pool.
19.3/3 At run time, Storage_Error is raised if an allocator using a
standard storage pool is evaluated after the elaboration of
the library_items of the partition has completed.
20 It is implementation defined whether the use of pragma Restrictions
results in a reduction in executable program size, storage requirements, or
execution time. If possible, the implementation should provide quantitative
descriptions of such effects for each restriction.
Implementation Advice
21 When feasible, the implementation should take advantage of the specified
restrictions to produce a more efficient implementation.
NOTES
22 34 The above Storage_Checks can be suppressed with pragma Suppress.
D.8 Monotonic Time
1/3 This subclause specifies a high-resolution, monotonic clock package.
Static Semantics
2 The following language-defined library package exists:
3 package Ada.Real_Time is
4 type Time is private;
Time_First : constant Time;
Time_Last : constant Time;
Time_Unit : constant := implementation-defined-real-number;
5 type Time_Span is private;
Time_Span_First : constant Time_Span;
Time_Span_Last : constant Time_Span;
Time_Span_Zero : constant Time_Span;
Time_Span_Unit : constant Time_Span;
6 Tick : constant Time_Span;
function Clock return Time;
7 function "+" (Left : Time; Right : Time_Span) return Time;
function "+" (Left : Time_Span; Right : Time) return Time;
function "-" (Left : Time; Right : Time_Span) return Time;
function "-" (Left : Time; Right : Time) return Time_Span;
8 function "<" (Left, Right : Time) return Boolean;
function "<="(Left, Right : Time) return Boolean;
function ">" (Left, Right : Time) return Boolean;
function ">="(Left, Right : Time) return Boolean;
9 function "+" (Left, Right : Time_Span) return Time_Span;
function "-" (Left, Right : Time_Span) return Time_Span;
function "-" (Right : Time_Span) return Time_Span;
function "*" (Left : Time_Span; Right : Integer) return Time_Span;
function "*" (Left : Integer; Right : Time_Span) return Time_Span;
function "/" (Left, Right : Time_Span) return Integer;
function "/" (Left : Time_Span; Right : Integer) return Time_Span;
10 function "abs"(Right : Time_Span) return Time_Span;
11/1 This paragraph was deleted.
12 function "<" (Left, Right : Time_Span) return Boolean;
function "<="(Left, Right : Time_Span) return Boolean;
function ">" (Left, Right : Time_Span) return Boolean;
function ">="(Left, Right : Time_Span) return Boolean;
13 function To_Duration (TS : Time_Span) return Duration;
function To_Time_Span (D : Duration) return Time_Span;
14/2 function Nanoseconds (NS : Integer) return Time_Span;
function Microseconds (US : Integer) return Time_Span;
function Milliseconds (MS : Integer) return Time_Span;
function Seconds (S : Integer) return Time_Span;
function Minutes (M : Integer) return Time_Span;
15 type Seconds_Count is range implementation-defined;
16 procedure Split
(T : in Time; SC : out Seconds_Count; TS : out Time_Span);
function Time_Of(SC : Seconds_Count; TS : Time_Span) return Time;
17 private
... -- not specified by the language
end Ada.Real_Time;
18 In this Annex, real time is defined to be the physical time as observed in
the external environment. The type Time is a time type as defined by 9.6;
values of this type may be used in a delay_until_statement. Values of this
type represent segments of an ideal time line. The set of values of the type
Time corresponds one-to-one with an implementation-defined range of
mathematical integers.
19 The Time value I represents the half-open real time interval that starts
with E+I*Time_Unit and is limited by E+(I+1)*Time_Unit, where Time_Unit is an
implementation-defined real number and E is an unspecified origin point, the
epoch, that is the same for all values of the type Time. It is not specified
by the language whether the time values are synchronized with any standard
time reference. For example, E can correspond to the time of system
initialization or it can correspond to the epoch of some time standard.
20 Values of the type Time_Span represent length of real time duration. The
set of values of this type corresponds one-to-one with an
implementation-defined range of mathematical integers. The Time_Span value
corresponding to the integer I represents the real-time duration I*Time_Unit.
21 Time_First and Time_Last are the smallest and largest values of the Time
type, respectively. Similarly, Time_Span_First and Time_Span_Last are the
smallest and largest values of the Time_Span type, respectively.
22 A value of type Seconds_Count represents an elapsed time, measured in
seconds, since the epoch.
Dynamic Semantics
23 Time_Unit is the smallest amount of real time representable by the Time
type; it is expressed in seconds. Time_Span_Unit is the difference between two
successive values of the Time type. It is also the smallest positive value of
type Time_Span. Time_Unit and Time_Span_Unit represent the same real time
duration. A clock tick is a real time interval during which the clock value
(as observed by calling the Clock function) remains constant. Tick is the
average length of such intervals.
24/2 The function To_Duration converts the value TS to a value of type
Duration. Similarly, the function To_Time_Span converts the value D to a value
of type Time_Span. For To_Duration, the result is rounded to the nearest value
of type Duration (away from zero if exactly halfway between two values). If
the result is outside the range of Duration, Constraint_Error is raised. For
To_Time_Span, the value of D is first rounded to the nearest integral multiple
of Time_Unit, away from zero if exactly halfway between two multiples. If the
rounded value is outside the range of Time_Span, Constraint_Error is raised.
Otherwise, the value is converted to the type Time_Span.
25 To_Duration(Time_Span_Zero) returns 0.0, and To_Time_Span(0.0) returns
Time_Span_Zero.
26/2 The functions Nanoseconds, Microseconds, Milliseconds, Seconds, and
Minutes convert the input parameter to a value of the type Time_Span. NS, US,
MS, S, and M are interpreted as a number of nanoseconds, microseconds,
milliseconds, seconds, and minutes respectively. The input parameter is first
converted to seconds and rounded to the nearest integral multiple of
Time_Unit, away from zero if exactly halfway between two multiples. If the
rounded value is outside the range of Time_Span, Constraint_Error is raised.
Otherwise, the rounded value is converted to the type Time_Span.
27 The effects of the operators on Time and Time_Span are as for the
operators defined for integer types.
28 The function Clock returns the amount of time since the epoch.
29 The effects of the Split and Time_Of operations are defined as follows,
treating values of type Time, Time_Span, and Seconds_Count as mathematical
integers. The effect of Split(T,SC,TS) is to set SC and TS to values such that
T*Time_Unit = SC*1.0 + TS*Time_Unit, and 0.0 <= TS*Time_Unit < 1.0. The value
returned by Time_Of(SC,TS) is the value T such that T*Time_Unit = SC*1.0 +
TS*Time_Unit.
Implementation Requirements
30 The range of Time values shall be sufficient to uniquely represent the
range of real times from program start-up to 50 years later. Tick shall be no
greater than 1 millisecond. Time_Unit shall be less than or equal to 20
microseconds.
31 Time_Span_First shall be no greater than -3600 seconds, and Time_Span_Last
shall be no less than 3600 seconds.
32 A clock jump is the difference between two successive distinct values of
the clock (as observed by calling the Clock function). There shall be no
backward clock jumps.
Documentation Requirements
33 The implementation shall document the values of Time_First, Time_Last,
Time_Span_First, Time_Span_Last, Time_Span_Unit, and Tick.
34 The implementation shall document the properties of the underlying time
base used for the clock and for type Time, such as the range of values
supported and any relevant aspects of the underlying hardware or operating
system facilities used.
35 The implementation shall document whether or not there is any
synchronization with external time references, and if such synchronization
exists, the sources of synchronization information, the frequency of
synchronization, and the synchronization method applied.
36/3 The implementation shall document any aspects of the external environment
that could interfere with the clock behavior as defined in this subclause.
Metrics
37/3 For the purpose of the metrics defined in this subclause, real time is
defined to be the International Atomic Time (TAI).
38 The implementation shall document the following metrics:
39 * An upper bound on the real-time duration of a clock tick. This is a
value D such that if t1 and t2 are any real times such that t1 < t2
and Clock(t1) = Clock(t2) then t2 - t1 <= D.
40 * An upper bound on the size of a clock jump.
41 * An upper bound on the drift rate of Clock with respect to real time.
This is a real number D such that
42 E*(1-D) <= (Clock(t+E) - Clock(t)) <= E*(1+D)
provided that: Clock(t) + E*(1+D) <= Time_Last.
43 * where Clock(t) is the value of Clock at time t, and E is a real time
duration not less than 24 hours. The value of E used for this metric
shall be reported.
44 * An upper bound on the execution time of a call to the Clock function,
in processor clock cycles.
45 * Upper bounds on the execution times of the operators of the types Time
and Time_Span, in processor clock cycles.
Implementation Permissions
46 Implementations targeted to machines with word size smaller than 32 bits
need not support the full range and granularity of the Time and Time_Span
types.
Implementation Advice
47 When appropriate, implementations should provide configuration mechanisms
to change the value of Tick.
48 It is recommended that Calendar.Clock and Real_Time.Clock be implemented
as transformations of the same time base.
49 It is recommended that the "best" time base which exists in the underlying
system be available to the application through Clock. "Best" may mean highest
accuracy or largest range.
NOTES
50/3 35 The rules in this subclause do not imply that the implementation
can protect the user from operator or installation errors which could
result in the clock being set incorrectly.
51 36 Time_Unit is the granularity of the Time type. In contrast, Tick
represents the granularity of Real_Time.Clock. There is no requirement
that these be the same.
D.9 Delay Accuracy
1/3 This subclause specifies performance requirements for the
delay_statement. The rules apply both to delay_relative_statement and to delay_-
until_statement. Similarly, they apply equally to a simple delay_statement and
to one which appears in a delay_alternative.
Dynamic Semantics
2 The effect of the delay_statement for Real_Time.Time is defined in terms
of Real_Time.Clock:
3 * If C(1) is a value of Clock read before a task executes a
delay_relative_statement with duration D, and C(2) is a value of Clock
read after the task resumes execution following that delay_statement,
then C(2) - C(1) >= D.
4 * If C is a value of Clock read after a task resumes execution following
a delay_until_statement with Real_Time.Time value T, then C >= T.
5 A simple delay_statement with a negative or zero value for the expiration
time does not cause the calling task to be blocked; it is nevertheless a
potentially blocking operation (see 9.5.1).
6/3 When a delay_statement appears in a delay_alternative of a
timed_entry_call the selection of the entry call is attempted, regardless of
the specified expiration time. When a delay_statement appears in a
select_alternative, and a call is queued on one of the open entries, the
selection of that entry call proceeds, regardless of the value of the delay
expression.
Documentation Requirements
7 The implementation shall document the minimum value of the delay
expression of a delay_relative_statement that causes the task to actually be
blocked.
8 The implementation shall document the minimum difference between the value
of the delay expression of a delay_until_statement and the value of
Real_Time.Clock, that causes the task to actually be blocked.
Metrics
9 The implementation shall document the following metrics:
10 * An upper bound on the execution time, in processor clock cycles, of a
delay_relative_statement whose requested value of the delay expression
is less than or equal to zero.
11 * An upper bound on the execution time, in processor clock cycles, of a
delay_until_statement whose requested value of the delay expression is
less than or equal to the value of Real_Time.Clock at the time of
executing the statement. Similarly, for Calendar.Clock.
12 * An upper bound on the lateness of a delay_relative_statement, for a
positive value of the delay expression, in a situation where the task
has sufficient priority to preempt the processor as soon as it becomes
ready, and does not need to wait for any other execution resources.
The upper bound is expressed as a function of the value of the delay
expression. The lateness is obtained by subtracting the value of the
delay expression from the actual duration. The actual duration is
measured from a point immediately before a task executes the
delay_statement to a point immediately after the task resumes
execution following this statement.
13 * An upper bound on the lateness of a delay_until_statement, in a
situation where the value of the requested expiration time is after
the time the task begins executing the statement, the task has
sufficient priority to preempt the processor as soon as it becomes
ready, and it does not need to wait for any other execution resources.
The upper bound is expressed as a function of the difference between
the requested expiration time and the clock value at the time the
statement begins execution. The lateness of a delay_until_statement is
obtained by subtracting the requested expiration time from the real
time that the task resumes execution following this statement.
D.10 Synchronous Task Control
1/3 This subclause describes a language-defined private semaphore (suspension
object), which can be used for two-stage suspend operations and as a simple
building block for implementing higher-level queues.
Static Semantics
2 The following language-defined package exists:
3/2 package Ada.Synchronous_Task_Control is
pragma Preelaborate(Synchronous_Task_Control);
4 type Suspension_Object is limited private;
procedure Set_True(S : in out Suspension_Object);
procedure Set_False(S : in out Suspension_Object);
function Current_State(S : Suspension_Object) return Boolean;
procedure Suspend_Until_True(S : in out Suspension_Object);
private
... -- not specified by the language
end Ada.Synchronous_Task_Control;
5 The type Suspension_Object is a by-reference type.
5.1/3 The following language-defined package exists:
5.2/3 package Ada.Synchronous_Task_Control.EDF is
procedure Suspend_Until_True_And_Set_Deadline
(S : in out Suspension_Object;
TS : in Ada.Real_Time.Time_Span);
end Ada.Synchronous_Task_Control.EDF;
Dynamic Semantics
6/2 An object of the type Suspension_Object has two visible states: True and
False. Upon initialization, its value is set to False.
7/2 The operations Set_True and Set_False are atomic with respect to each
other and with respect to Suspend_Until_True; they set the state to True and
False respectively.
8 Current_State returns the current state of the object.
9/2 The procedure Suspend_Until_True blocks the calling task until the state
of the object S is True; at that point the task becomes ready and the state of
the object becomes False.
10 Program_Error is raised upon calling Suspend_Until_True if another task is
already waiting on that suspension object. Suspend_Until_True is a potentially
blocking operation (see 9.5.1).
10.1/3 The procedure Suspend_Until_True_And_Set_Deadline blocks the calling
task until the state of the object S is True; at that point the task becomes
ready with a deadline of Ada.Real_Time.Clock + TS, and the state of the object
becomes False. Program_Error is raised upon calling
Suspend_Until_True_And_Set_Deadline if another task is already waiting on that
suspension object. Suspend_Until_True_And_Set_Deadline is a potentially
blocking operation.
Implementation Requirements
11 The implementation is required to allow the calling of Set_False and
Set_True during any protected action, even one that has its ceiling priority
in the Interrupt_Priority range.
NOTES
12/3 37 More complex schemes, such as setting the deadline relative to
when Set_True is called, can be programmed using a protected object.
D.10.1 Synchronous Barriers
1/3 This subclause introduces a language-defined package to synchronously
release a group of tasks after the number of blocked tasks reaches a specified
count value.
Static Semantics
2/3 The following language-defined library package exists:
3/3 package Ada.Synchronous_Barriers is
pragma Preelaborate(Synchronous_Barriers);
4/3 subtype Barrier_Limit
is Positive range 1 .. implementation-defined;
5/3 type Synchronous_Barrier
(Release_Threshold : Barrier_Limit) is limited private;
6/3 procedure Wait_For_Release
(The_Barrier : in out Synchronous_Barrier;
Notified : out Boolean);
7/3 private
-- not specified by the language
end Ada.Synchronous_Barriers;
8/3 Type Synchronous_Barrier needs finalization (see 7.6).
Dynamic Semantics
9/3 Each call to Wait_For_Release blocks the calling task until the number of
blocked tasks associated with the Synchronous_Barrier object is equal to
Release_Threshold, at which time all blocked tasks are released. Notified is
set to True for one of the released tasks, and set to False for all other
released tasks.
10/3 The mechanism for determining which task sets Notified to True is
implementation defined.
11/3 Once all tasks have been released, a Synchronous_Barrier object may be
reused to block another Release_Threshold number of tasks.
12/3 As the first step of the finalization of a Synchronous_Barrier, each
blocked task is unblocked and Program_Error is raised at the place of the call
to Wait_For_Release.
13/3 It is implementation defined whether an abnormal task which is waiting on
a Synchronous_Barrier object is aborted immediately or aborted when the tasks
waiting on the object are released.
14/3 Wait_For_Release is a potentially blocking operation (see 9.5.1).
Bounded (Run-Time) Errors
15/3 It is a bounded error to call Wait_For_Release on a Synchronous_Barrier
object after that object is finalized. If the error is detected, Program_Error
is raised. Otherwise, the call proceeds normally, which may leave a task
blocked forever.
D.11 Asynchronous Task Control
1/3 This subclause introduces a language-defined package to do asynchronous
suspend/resume on tasks. It uses a conceptual held priority value to represent
the task's held state.
Static Semantics
2 The following language-defined library package exists:
3/2 with Ada.Task_Identification;
package Ada.Asynchronous_Task_Control is
pragma Preelaborate(Asynchronous_Task_Control);
procedure Hold(T : in Ada.Task_Identification.Task_Id);
procedure Continue(T : in Ada.Task_Identification.Task_Id);
function Is_Held(T : Ada.Task_Identification.Task_Id)
return Boolean;
end Ada.Asynchronous_Task_Control;
Dynamic Semantics
4/2 After the Hold operation has been applied to a task, the task becomes
held. For each processor there is a conceptual idle task, which is always
ready. The base priority of the idle task is below System.Any_Priority'First.
The held priority is a constant of the type Integer whose value is below the
base priority of the idle task.
4.1/2 For any priority below System.Any_Priority'First, the task dispatching
policy is FIFO_Within_Priorities.
5/2 The Hold operation sets the state of T to held. For a held task, the
active priority is reevaluated as if the base priority of the task were the
held priority.
6/2 The Continue operation resets the state of T to not-held; its active
priority is then reevaluated as determined by the task dispatching policy
associated with its base priority.
7 The Is_Held function returns True if and only if T is in the held state.
8 As part of these operations, a check is made that the task identified by T
is not terminated. Tasking_Error is raised if the check fails. Program_Error
is raised if the value of T is Null_Task_Id.
Erroneous Execution
9 If any operation in this package is called with a parameter T that
specifies a task object that no longer exists, the execution of the program is
erroneous.
Implementation Permissions
10 An implementation need not support Asynchronous_Task_Control if it is
infeasible to support it in the target environment.
NOTES
11 38 It is a consequence of the priority rules that held tasks cannot
be dispatched on any processor in a partition (unless they are
inheriting priorities) since their priorities are defined to be below
the priority of any idle task.
12 39 The effect of calling Get_Priority and Set_Priority on a Held task
is the same as on any other task.
13 40 Calling Hold on a held task or Continue on a non-held task has no
effect.
14 41 The rules affecting queuing are derived from the above rules, in
addition to the normal priority rules:
15 * When a held task is on the ready queue, its priority is so low as
to never reach the top of the queue as long as there are other
tasks on that queue.
16 * If a task is executing in a protected action, inside a rendezvous,
or is inheriting priorities from other sources (e.g. when
activated), it continues to execute until it is no longer
executing the corresponding construct.
17 * If a task becomes held while waiting (as a caller) for a
rendezvous to complete, the active priority of the accepting task
is not affected.
18/1 * If a task becomes held while waiting in a selective_accept, and an
entry call is issued to one of the open entries, the corresponding
accept_alternative executes. When the rendezvous completes, the
active priority of the accepting task is lowered to the held
priority (unless it is still inheriting from other sources), and
the task does not execute until another Continue.
19 * The same holds if the held task is the only task on a protected
entry queue whose barrier becomes open. The corresponding entry
body executes.
D.12 Other Optimizations and Determinism Rules
1/3 This subclause describes various requirements for improving the response
and determinism in a real-time system.
Implementation Requirements
2 If the implementation blocks interrupts (see C.3) not as a result of
direct user action (e.g. an execution of a protected action) there shall be an
upper bound on the duration of this blocking.
3 The implementation shall recognize entry-less protected types. The
overhead of acquiring the execution resource of an object of such a type (see
9.5.1) shall be minimized. In particular, there should not be any overhead due
to evaluating entry_barrier conditions.
4 Unchecked_Deallocation shall be supported for terminated tasks that are
designated by access types, and shall have the effect of releasing all the
storage associated with the task. This includes any run-time system or heap
storage that has been implicitly allocated for the task by the implementation.
Documentation Requirements
5 The implementation shall document the upper bound on the duration of
interrupt blocking caused by the implementation. If this is different for
different interrupts or interrupt priority levels, it should be documented for
each case.
Metrics
6 The implementation shall document the following metric:
7 * The overhead associated with obtaining a mutual-exclusive access to an
entry-less protected object. This shall be measured in the following
way:
8 For a protected object of the form:
9 protected Lock is
procedure Set;
function Read return Boolean;
private
Flag : Boolean := False;
end Lock;
10 protected body Lock is
procedure Set is
begin
Flag := True;
end Set;
function Read return Boolean
Begin
return Flag;
end Read;
end Lock;
11 The execution time, in processor clock cycles, of a call to Set. This
shall be measured between the point just before issuing the call, and
the point just after the call completes. The function Read shall be
called later to verify that Set was indeed called (and not optimized
away). The calling task shall have sufficiently high priority as to
not be preempted during the measurement period. The protected object
shall have sufficiently high ceiling priority to allow the task to
call Set.
12 For a multiprocessor, if supported, the metric shall be reported for
the case where no contention (on the execution resource) exists from
tasks executing on other processors.
D.13 The Ravenscar Profile
1/3 This subclause defines the Ravenscar profile.
Paragraphs 2 and 3 were moved to 13.12, "
Pragma Restrictions and Pragma Profile".
Legality Rules
4/3 The profile_identifier Ravenscar is a usage profile (see 13.12). For usage
profile Ravenscar, there shall be no profile_pragma_argument_associations.
Static Semantics
5/3 The usage profile Ravenscar is equivalent to the following set of pragmas:
6/4 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);
Paragraph 7 was deleted.
Implementation Requirements
8/4 This paragraph was deleted.
Implementation Advice
9/3 On a multiprocessor system, an implementation should support a fully
partitioned approach. Each processor should have separate and disjoint ready
queues.
NOTES
10/3 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.
11/4 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.
12/4 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.
D.14 Execution Time
1/3 This subclause describes a language-defined package to measure execution
time.
Static Semantics
2/2 The following language-defined library package exists:
3/2 with Ada.Task_Identification;
with Ada.Real_Time; use Ada.Real_Time;
package Ada.Execution_Time is
4/2 type CPU_Time is private;
CPU_Time_First : constant CPU_Time;
CPU_Time_Last : constant CPU_Time;
CPU_Time_Unit : constant := implementation-defined-real-number;
CPU_Tick : constant Time_Span;
5/2 function Clock
(T : Ada.Task_Identification.Task_Id
:= Ada.Task_Identification.Current_Task)
return CPU_Time;
6/2 function "+" (Left : CPU_Time; Right : Time_Span) return CPU_Time;
function "+" (Left : Time_Span; Right : CPU_Time) return CPU_Time;
function "-" (Left : CPU_Time; Right : Time_Span) return CPU_Time;
function "-" (Left : CPU_Time; Right : CPU_Time) return Time_Span;
7/2 function "<" (Left, Right : CPU_Time) return Boolean;
function "<=" (Left, Right : CPU_Time) return Boolean;
function ">" (Left, Right : CPU_Time) return Boolean;
function ">=" (Left, Right : CPU_Time) return Boolean;
8/2 procedure Split
(T : in CPU_Time; SC : out Seconds_Count; TS : out Time_Span);
9/2 function Time_Of (SC : Seconds_Count;
TS : Time_Span := Time_Span_Zero) return CPU_Time;
9.1/3 Interrupt_Clocks_Supported
: constant Boolean := implementation-defined;
9.2/3 Separate_Interrupt_Clocks_Supported : constant Boolean :=
implementation-defined;
9.3/3 function Clock_For_Interrupts return CPU_Time;
10/2 private
... -- not specified by the language
end Ada.Execution_Time;
11/3 The execution time or CPU time of a given task is defined as the time
spent by the system executing that task, including the time spent executing
run-time or system services on its behalf. The mechanism used to measure
execution time is implementation defined. The Boolean constant
Interrupt_Clocks_Supported is set to True if the implementation separately
accounts for the execution time of interrupt handlers. If it is set to False
it is implementation defined which task, if any, is charged the execution time
that is consumed by interrupt handlers. The Boolean constant
Separate_Interrupt_Clocks_Supported is set to True if the implementation
separately accounts for the execution time of individual interrupt handlers
(see D.14.3).
12/2 The type CPU_Time represents the execution time of a task. The set of
values of this type corresponds one-to-one with an implementation-defined
range of mathematical integers.
13/2 The CPU_Time value I represents the half-open execution-time interval
that starts with I*CPU_Time_Unit and is limited by (I+1)*CPU_Time_Unit, where
CPU_Time_Unit is an implementation-defined real number. For each task, the
execution time value is set to zero at the creation of the task.
14/2 CPU_Time_First and CPU_Time_Last are the smallest and largest values of
the CPU_Time type, respectively.
14.1/3 The execution time value for the function Clock_For_Interrupts is
initialized to zero.
Dynamic Semantics
15/2 CPU_Time_Unit is the smallest amount of execution time representable by
the CPU_Time type; it is expressed in seconds. A CPU clock tick is an
execution time interval during which the clock value (as observed by calling
the Clock function) remains constant. CPU_Tick is the average length of such
intervals.
16/2 The effects of the operators on CPU_Time and Time_Span are as for the
operators defined for integer types.
17/2 The function Clock returns the current execution time of the task
identified by T; Tasking_Error is raised if that task has terminated;
Program_Error is raised if the value of T is Task_Identification.Null_Task_Id.
18/2 The effects of the Split and Time_Of operations are defined as follows,
treating values of type CPU_Time, Time_Span, and Seconds_Count as mathematical
integers. The effect of Split (T, SC, TS) is to set SC and TS to values such
that T*CPU_Time_Unit = SC*1.0 + TS*CPU_Time_Unit, and 0.0 <= TS*CPU_Time_Unit
< 1.0. The value returned by Time_Of(SC,TS) is the execution-time value T such
that T*CPU_Time_Unit=SC*1.0 + TS*CPU_Time_Unit.
18.1/3 The function Clock_For_Interrupts returns the total cumulative time
spent executing within all interrupt handlers. This time is not allocated to
any task execution time clock. If Interrupt_Clocks_Supported is set to False
the function raises Program_Error.
Erroneous Execution
19/2 For a call of Clock, if the task identified by T no longer exists, the
execution of the program is erroneous.
Implementation Requirements
20/2 The range of CPU_Time values shall be sufficient to uniquely represent
the range of execution times from the task start-up to 50 years of execution
time later. CPU_Tick shall be no greater than 1 millisecond.
Documentation Requirements
21/2 The implementation shall document the values of CPU_Time_First,
CPU_Time_Last, CPU_Time_Unit, and CPU_Tick.
22/2 The implementation shall document the properties of the underlying
mechanism used to measure execution times, such as the range of values
supported and any relevant aspects of the underlying hardware or operating
system facilities used.
Metrics
23/2 The implementation shall document the following metrics:
24/2 * An upper bound on the execution-time duration of a clock tick. This
is a value D such that if t1 and t2 are any execution times of a given
task such that t1 < t2 and Clock(t1) = Clock(t2) then t2 - t1 <= D.
25/2 * An upper bound on the size of a clock jump. A clock jump is the
difference between two successive distinct values of an execution-time
clock (as observed by calling the Clock function with the same
Task_Id).
26/2 * An upper bound on the execution time of a call to the Clock function,
in processor clock cycles.
27/2 * Upper bounds on the execution times of the operators of the type
CPU_Time, in processor clock cycles.
Implementation Permissions
28/2 Implementations targeted to machines with word size smaller than 32 bits
need not support the full range and granularity of the CPU_Time type.
Implementation Advice
29/2 When appropriate, implementations should provide configuration mechanisms
to change the value of CPU_Tick.
D.14.1 Execution Time Timers
1/3 This subclause describes a language-defined package that provides a
facility for calling a handler when a task has used a defined amount of CPU
time.
Static Semantics
2/2 The following language-defined library package exists:
3/2 with System;
package Ada.Execution_Time.Timers is
4/2 type Timer (T : not null access constant
Ada.Task_Identification.Task_Id) is
tagged limited private;
5/2 type Timer_Handler is
access protected procedure (TM : in out Timer);
6/2 Min_Handler_Ceiling : constant System.Any_Priority :=
implementation-defined;
7/2 procedure Set_Handler (TM : in out Timer;
In_Time : in Time_Span;
Handler : in Timer_Handler);
procedure Set_Handler (TM : in out Timer;
At_Time : in CPU_Time;
Handler : in Timer_Handler);
function Current_Handler (TM : Timer) return Timer_Handler;
procedure Cancel_Handler (TM : in out Timer;
Cancelled : out Boolean);
8/2 function Time_Remaining (TM : Timer) return Time_Span;
9/2 Timer_Resource_Error : exception;
10/2 private
... -- not specified by the language
end Ada.Execution_Time.Timers;
11/2 The type Timer represents an execution-time event for a single task and
is capable of detecting execution-time overruns. The access discriminant T
identifies the task concerned. The type Timer needs finalization (see 7.6).
12/2 An object of type Timer is said to be set if it is associated with a
nonnull value of type Timer_Handler and cleared otherwise. All Timer objects
are initially cleared.
13/2 The type Timer_Handler identifies a protected procedure to be executed by
the implementation when the timer expires. Such a protected procedure is
called a handler.
Dynamic Semantics
14/2 When a Timer object is created, or upon the first call of a Set_Handler
procedure with the timer as parameter, the resources required to operate an
execution-time timer based on the associated execution-time clock are
allocated and initialized. If this operation would exceed the available
resources, Timer_Resource_Error is raised.
15/3 The procedures Set_Handler associate the handler Handler with the timer
TM: if Handler is null, the timer is cleared; otherwise, it is set. The first
procedure Set_Handler loads the timer TM with an interval specified by the
Time_Span parameter. In this mode, the timer TM expires when the execution
time of the task identified by TM.T.all has increased by In_Time; if In_Time
is less than or equal to zero, the timer expires immediately. The second
procedure Set_Handler loads the timer TM with the absolute value specified by
At_Time. In this mode, the timer TM expires when the execution time of the
task identified by TM.T.all reaches At_Time; if the value of At_Time has
already been reached when Set_Handler is called, the timer expires immediately.
16/2 A call of a procedure Set_Handler for a timer that is already set
replaces the handler and the (absolute or relative) execution time; if Handler
is not null, the timer remains set.
17/2 When a timer expires, the associated handler is executed, passing the
timer as parameter. The initial action of the execution of the handler is to
clear the event.
18/3 The function Current_Handler returns the handler associated with the
timer TM if that timer is set; otherwise, it returns null.
19/3 The procedure Cancel_Handler clears the timer if it is set. Cancelled is
assigned True if the timer was set prior to it being cleared; otherwise, it is
assigned False.
20/3 The function Time_Remaining returns the execution time interval that
remains until the timer TM would expire, if that timer is set; otherwise, it
returns Time_Span_Zero.
21/2 The constant Min_Handler_Ceiling is the minimum ceiling priority required
for a protected object with a handler to ensure that no ceiling violation will
occur when that handler is invoked.
22/2 As part of the finalization of an object of type Timer, the timer is
cleared.
23/2 For all the subprograms defined in this package, Tasking_Error is raised
if the task identified by TM.T.all has terminated, and Program_Error is raised
if the value of TM.T.all is Task_Identification.Null_Task_Id.
24/2 An exception propagated from a handler invoked as part of the expiration
of a timer has no effect.
Erroneous Execution
25/2 For a call of any of the subprograms defined in this package, if the task
identified by TM.T.all no longer exists, the execution of the program is
erroneous.
Implementation Requirements
26/2 For a given Timer object, the implementation shall perform the operations
declared in this package atomically with respect to any of these operations on
the same Timer object. The replacement of a handler by a call of Set_Handler
shall be performed atomically with respect to the execution of the handler.
27/2 When an object of type Timer is finalized, the system resources used by
the timer shall be deallocated.
Implementation Permissions
28/3 Implementations may limit the number of timers that can be defined for
each task. If this limit is exceeded, then Timer_Resource_Error is raised.
NOTES
29/2 45 A Timer_Handler can be associated with several Timer objects.
D.14.2 Group Execution Time Budgets
1/3 This subclause describes a language-defined package to assign execution
time budgets to groups of tasks.
Static Semantics
2/2 The following language-defined library package exists:
3/3 with System;
with System.Multiprocessors;
package Ada.Execution_Time.Group_Budgets is
4/3 type Group_Budget(CPU : System.Multiprocessors.CPU :=
System.Multiprocessors.CPU'First)
is tagged limited private;
5/2 type Group_Budget_Handler is access
protected procedure (GB : in out Group_Budget);
6/2 type Task_Array is array (Positive range <>) of
Ada.Task_Identification.Task_Id;
7/2 Min_Handler_Ceiling : constant System.Any_Priority :=
implementation-defined;
8/2 procedure Add_Task (GB : in out Group_Budget;
T : in Ada.Task_Identification.Task_Id);
procedure Remove_Task (GB: in out Group_Budget;
T : in Ada.Task_Identification.Task_Id);
function Is_Member (GB : Group_Budget;
T : Ada.Task_Identification.Task_Id) return Boolean;
function Is_A_Group_Member
(T : Ada.Task_Identification.Task_Id) return Boolean;
function Members (GB : Group_Budget) return Task_Array;
9/2 procedure Replenish (GB : in out Group_Budget; To : in Time_Span);
procedure Add (GB : in out Group_Budget; Interval : in Time_Span);
function Budget_Has_Expired (GB : Group_Budget) return Boolean;
function Budget_Remaining (GB : Group_Budget) return Time_Span;
10/2 procedure Set_Handler (GB : in out Group_Budget;
Handler : in Group_Budget_Handler);
function Current_Handler (GB : Group_Budget)
return Group_Budget_Handler;
procedure Cancel_Handler (GB : in out Group_Budget;
Cancelled : out Boolean);
11/2 Group_Budget_Error : exception;
12/2 private
-- not specified by the language
end Ada.Execution_Time.Group_Budgets;
13/2 The type Group_Budget represents an execution time budget to be used by a
group of tasks. The type Group_Budget needs finalization (see 7.6). A task can
belong to at most one group. Tasks of any priority can be added to a group.
14/2 An object of type Group_Budget has an associated nonnegative value of
type Time_Span known as its budget, which is initially Time_Span_Zero. The
type Group_Budget_Handler identifies a protected procedure to be executed by
the implementation when the budget is exhausted, that is, reaches zero. Such a
protected procedure is called a handler.
15/2 An object of type Group_Budget also includes a handler, which is a value
of type Group_Budget_Handler. The handler of the object is said to be set if
it is not null and cleared otherwise. The handler of all Group_Budget objects
is initially cleared.
Dynamic Semantics
16/2 The procedure Add_Task adds the task identified by T to the group GB; if
that task is already a member of some other group, Group_Budget_Error is
raised.
17/2 The procedure Remove_Task removes the task identified by T from the group
GB; if that task is not a member of the group GB, Group_Budget_Error is
raised. After successful execution of this procedure, the task is no longer a
member of any group.
18/3 The function Is_Member returns True if the task identified by T is a
member of the group GB; otherwise, it returns False.
19/3 The function Is_A_Group_Member returns True if the task identified by T
is a member of some group; otherwise, it returns False.
20/2 The function Members returns an array of values of type
Task_Identification.Task_Id identifying the members of the group GB. The order
of the components of the array is unspecified.
21/3 The procedure Replenish loads the group budget GB with To as the
Time_Span value. The exception Group_Budget_Error is raised if the Time_Span
value To is nonpositive. Any execution on CPU of any member of the group of
tasks results in the budget counting down, unless exhausted. When the budget
becomes exhausted (reaches Time_Span_Zero), the associated handler is executed
if the handler of group budget GB is set. Nevertheless, the tasks continue to
execute.
22/2 The procedure Add modifies the budget of the group GB. A positive value
for Interval increases the budget. A negative value for Interval reduces the
budget, but never below Time_Span_Zero. A zero value for Interval has no
effect. A call of procedure Add that results in the value of the budget going
to Time_Span_Zero causes the associated handler to be executed if the handler
of the group budget GB is set.
23/3 The function Budget_Has_Expired returns True if the budget of group GB is
exhausted (equal to Time_Span_Zero); otherwise, it returns False.
24/2 The function Budget_Remaining returns the remaining budget for the group
GB. If the budget is exhausted it returns Time_Span_Zero. This is the minimum
value for a budget.
25/3 The procedure Set_Handler associates the handler Handler with the
Group_Budget GB: if Handler is null, the handler of Group_Budget is cleared;
otherwise, it is set.
26/2 A call of Set_Handler for a Group_Budget that already has a handler set
replaces the handler; if Handler is not null, the handler for Group_Budget
remains set.
27/3 The function Current_Handler returns the handler associated with the
group budget GB if the handler for that group budget is set; otherwise, it
returns null.
28/3 The procedure Cancel_Handler clears the handler for the group budget if
it is set. Cancelled is assigned True if the handler for the group budget was
set prior to it being cleared; otherwise, it is assigned False.
29/2 The constant Min_Handler_Ceiling is the minimum ceiling priority required
for a protected object with a handler to ensure that no ceiling violation will
occur when that handler is invoked.
30/2 The precision of the accounting of task execution time to a Group_Budget
is the same as that defined for execution-time clocks from the parent package.
31/2 As part of the finalization of an object of type Group_Budget all member
tasks are removed from the group identified by that object.
32/3 If a task is a member of a Group_Budget when it terminates, then as part
of the finalization of the task it is removed from the group.
33/2 For all the operations defined in this package, Tasking_Error is raised
if the task identified by T has terminated, and Program_Error is raised if the
value of T is Task_Identification.Null_Task_Id.
34/2 An exception propagated from a handler invoked when the budget of a group
of tasks becomes exhausted has no effect.
Erroneous Execution
35/2 For a call of any of the subprograms defined in this package, if the task
identified by T no longer exists, the execution of the program is erroneous.
Implementation Requirements
36/2 For a given Group_Budget object, the implementation shall perform the
operations declared in this package atomically with respect to any of these
operations on the same Group_Budget object. The replacement of a handler, by a
call of Set_Handler, shall be performed atomically with respect to the
execution of the handler.
NOTES
37/2 46 Clearing or setting of the handler of a group budget does not
change the current value of the budget. Exhaustion or loading of a
budget does not change whether the handler of the group budget is set
or cleared.
38/2 47 A Group_Budget_Handler can be associated with several Group_Budget
objects.
D.14.3 Execution Time of Interrupt Handlers
1/3 This subclause describes a language-defined package to measure the
execution time of interrupt handlers.
Static Semantics
2/3 The following language-defined library package exists:
3/3 with Ada.Interrupts;
package Ada.Execution_Time.Interrupts is
function Clock (Interrupt : Ada.Interrupts.Interrupt_Id)
return CPU_Time;
function Supported (Interrupt : Ada.Interrupts.Interrupt_Id)
return Boolean;
end Ada.Execution_Time.Interrupts;
4/3 The execution time or CPU time of a given interrupt Interrupt is defined
as the time spent by the system executing interrupt handlers identified by
Interrupt, including the time spent executing run-time or system services on
its behalf. The mechanism used to measure execution time is implementation
defined. Time spent executing interrupt handlers is distinct from time spent
executing any task.
5/3 For each interrupt, the execution time value is initially set to zero.
Dynamic Semantics
6/3 The function Clock returns the current cumulative execution time of the
interrupt identified by Interrupt. If Separate_Interrupt_Clocks_Supported is
set to False the function raises Program_Error.
7/3 The function Supported returns True if the implementation is monitoring
the execution time of the interrupt identified by Interrupt; otherwise, it
returns False. For any Interrupt_Id Interrupt for which Supported(Interrupt)
returns False, the function Clock(Interrupt) will return a value equal to
Ada.Execution_Time.Time_Of(0).
D.15 Timing Events
1/3 This subclause describes a language-defined package to allow user-defined
protected procedures to be executed at a specified time without the need for a
task or a delay statement.
Static Semantics
2/2 The following language-defined library package exists:
3/2 package Ada.Real_Time.Timing_Events is
4/2 type Timing_Event is tagged limited private;
type Timing_Event_Handler
is access protected procedure (Event : in out Timing_Event);
5/2 procedure Set_Handler (Event : in out Timing_Event;
At_Time : in Time;
Handler : in Timing_Event_Handler);
procedure Set_Handler (Event : in out Timing_Event;
In_Time : in Time_Span;
Handler : in Timing_Event_Handler);
function Current_Handler (Event : Timing_Event)
return Timing_Event_Handler;
procedure Cancel_Handler (Event : in out Timing_Event;
Cancelled : out Boolean);
6/2 function Time_Of_Event (Event : Timing_Event) return Time;
7/2 private
... -- not specified by the language
end Ada.Real_Time.Timing_Events;
8/2 The type Timing_Event represents a time in the future when an event is to
occur. The type Timing_Event needs finalization (see 7.6).
9/2 An object of type Timing_Event is said to be set if it is associated with
a nonnull value of type Timing_Event_Handler and cleared otherwise. All
Timing_Event objects are initially cleared.
10/2 The type Timing_Event_Handler identifies a protected procedure to be
executed by the implementation when the timing event occurs. Such a protected
procedure is called a handler.
Dynamic Semantics
11/3 The procedures Set_Handler associate the handler Handler with the event
Event: if Handler is null, the event is cleared; otherwise, it is set. The
first procedure Set_Handler sets the execution time for the event to be
At_Time. The second procedure Set_Handler sets the execution time for the
event to be Real_Time.Clock + In_Time.
12/2 A call of a procedure Set_Handler for an event that is already set
replaces the handler and the time of execution; if Handler is not null, the
event remains set.
13/2 As soon as possible after the time set for the event, the handler is
executed, passing the event as parameter. The handler is only executed if the
timing event is in the set state at the time of execution. The initial action
of the execution of the handler is to clear the event.
14/2 If the Ceiling_Locking policy (see D.3) is in effect when a procedure
Set_Handler is called, a check is made that the ceiling priority of
Handler.all is Interrupt_Priority'Last. If the check fails, Program_Error is
raised.
15/3 If a procedure Set_Handler is called with zero or negative In_Time or
with At_Time indicating a time in the past, then the handler is executed as
soon as possible after the completion of the call of Set_Handler.
16/3 The function Current_Handler returns the handler associated with the
event Event if that event is set; otherwise, it returns null.
17/3 The procedure Cancel_Handler clears the event if it is set. Cancelled is
assigned True if the event was set prior to it being cleared; otherwise, it is
assigned False.
18/3 The function Time_Of_Event returns the time of the event if the event is
set; otherwise, it returns Real_Time.Time_First.
19/2 As part of the finalization of an object of type Timing_Event, the
Timing_Event is cleared.
20/2 If several timing events are set for the same time, they are executed in
FIFO order of being set.
21/2 An exception propagated from a handler invoked by a timing event has no
effect.
Implementation Requirements
22/2 For a given Timing_Event object, the implementation shall perform the
operations declared in this package atomically with respect to any of these
operations on the same Timing_Event object. The replacement of a handler by a
call of Set_Handler shall be performed atomically with respect to the
execution of the handler.
Metrics
23/2 The implementation shall document the following metric:
24/3 * An upper bound on the lateness of the execution of a handler. That
is, the maximum time between the time specified for the event and when
a handler is actually invoked assuming no other handler or task is
executing during this interval.
Implementation Advice
25/2 The protected handler procedure should be executed directly by the
real-time clock interrupt mechanism.
NOTES
26/2 48 Since a call of Set_Handler is not a potentially blocking
operation, it can be called from within a handler.
27/2 49 A Timing_Event_Handler can be associated with several Timing_Event
objects.
D.16 Multiprocessor Implementation
1/3 This subclause allows implementations on multiprocessor platforms to be
configured.
Static Semantics
2/3 The following language-defined library package exists:
3/3 package System.Multiprocessors is
pragma Preelaborate(Multiprocessors);
4/3 type CPU_Range is range 0 .. implementation-defined;
Not_A_Specific_CPU : constant CPU_Range := 0;
subtype CPU is CPU_Range range 1 .. CPU_Range'Last;
5/3 function Number_Of_CPUs return CPU;
end System.Multiprocessors;
6/3 A call of Number_Of_CPUs returns the number of processors available to the
program. Within a given partition, each call on Number_Of_CPUs will return the
same value.
7/3 For a task type (including the anonymous type of a
single_task_declaration) or subprogram, the following language-defined
representation aspect may be specified:
8/3 CPU The aspect CPU is an expression, which shall be of type
System.Multiprocessors.CPU_Range.
Legality Rules
9/3 If the CPU aspect is specified for a subprogram, the expression shall be
static.
10/3 The CPU aspect shall not be specified on a task interface type.
Dynamic Semantics
11/4 The expression specified for the CPU aspect of a task type is evaluated
each time an object of the task type is created (see 9.1). The CPU value is
then associated with the task object.
12/3 The CPU aspect has no effect if it is specified for a subprogram other
than the main subprogram; the CPU value is not associated with any task.
13/3 The CPU value is associated with the environment task if the CPU aspect
is specified for the main subprogram. If the CPU aspect is not specified for
the main subprogram it is implementation defined on which processor the
environment task executes.
14/3 The CPU value determines the processor on which the task will activate
and execute; the task is said to be assigned to that processor. If the CPU
value is Not_A_Specific_CPU, then the task is not assigned to a processor. A
task without a CPU aspect specified will activate and execute on the same
processor as its activating task if the activating task is assigned a
processor. If the CPU value is not in the range of
System.Multiprocessors.CPU_Range or is greater than Number_Of_CPUs the task is
defined to have failed, and it becomes a completed task (see 9.2).
D.16.1 Multiprocessor Dispatching Domains
1/3 This subclause allows implementations on multiprocessor platforms to be
partitioned into distinct dispatching domains during program startup.
Static Semantics
2/3 The following language-defined library package exists:
3/3 with Ada.Real_Time;
with Ada.Task_Identification;
package System.Multiprocessors.Dispatching_Domains is
4/3 Dispatching_Domain_Error : exception;
5/3 type Dispatching_Domain (<>) is limited private;
6/3 System_Dispatching_Domain : constant Dispatching_Domain;
7/4 function Create
(First : CPU; Last : CPU_Range) return Dispatching_Domain;
8/3 function Get_First_CPU (Domain : Dispatching_Domain) return CPU;
9/4 function Get_Last_CPU
(Domain : Dispatching_Domain) return CPU_Range;
9.1/4 type CPU_Set is array(CPU range <>) of Boolean;
9.2/4 function Create (Set : CPU_Set) return Dispatching_Domain;
9.3/4 function Get_CPU_Set (Domain : Dispatching_Domain) return CPU_Set;
10/3 function Get_Dispatching_Domain
(T : Ada.Task_Identification.Task_Id :=
Ada.Task_Identification.Current_Task)
return Dispatching_Domain;
11/3 procedure Assign_Task
(Domain : in out Dispatching_Domain;
CPU : in CPU_Range := Not_A_Specific_CPU;
T : in Ada.Task_Identification.Task_Id :=
Ada.Task_Identification.Current_Task);
12/3 procedure Set_CPU
(CPU : in CPU_Range;
T : in Ada.Task_Identification.Task_Id :=
Ada.Task_Identification.Current_Task);
13/3 function Get_CPU
(T : Ada.Task_Identification.Task_Id :=
Ada.Task_Identification.Current_Task)
return CPU_Range;
14/3 procedure Delay_Until_And_Set_CPU
(Delay_Until_Time : in Ada.Real_Time.Time; CPU : in CPU_Range);
15/3 private
... -- not specified by the language
end System.Multiprocessors.Dispatching_Domains;
16/4 A dispatching domain represents a set of processors on which a task may
execute. Each processor is contained within exactly one dispatching domain. An
object of type Dispatching_Domain identifies a dispatching domain.
System_Dispatching_Domain identifies a domain that contains the processor or
processors on which the environment task executes. At program start-up all
processors are contained within this domain.
17/3 For a task type (including the anonymous type of a
single_task_declaration), the following language-defined representation aspect
may be specified:
18/3 Dispatching_Domain
The value of aspect Dispatching_Domain is an expression, which
shall be of type Dispatching_Domains.Dispatching_Domain. This
aspect is the domain to which the task (or all objects of the
task type) are assigned.
Legality Rules
19/3 The Dispatching_Domain aspect shall not be specified for a task interface.
Dynamic Semantics
20/4 The expression specified for the Dispatching_Domain aspect of a task type
is evaluated each time an object of the task type is created (see 9.1). If the
identified dispatching domain is empty, then Dispatching_Domain_Error is
raised; otherwise the newly created task is assigned to the domain identified
by the value of the expression.
21/3 If a task is not explicitly assigned to any domain, it is assigned to
that of the activating task. A task always executes on some CPU in its domain.
22/4 If both the dispatching domain and CPU are specified for a task, and the
CPU value is not contained within the set of processors for the domain (and is
not Not_A_Specific_CPU), the activation of the task is defined to have failed,
and it becomes a completed task (see 9.2).
23/4 The function Create with First and Last parameters creates and returns a
dispatching domain containing all the processors in the range First .. Last.
The function Create with a Set parameter creates and returns a dispatching
domain containing the processors for which Set(I) is True. These processors
are removed from System_Dispatching_Domain. A call of Create will raise
Dispatching_Domain_Error if any designated processor is not currently in
System_Dispatching_Domain, or if the system cannot support a distinct domain
over the processors identified, or if a processor has a task assigned to it,
or if the allocation would leave System_Dispatching_Domain empty. A call of
Create will raise Dispatching_Domain_Error if the calling task is not the
environment task, or if Create is called after the call to the main subprogram.
24/4 The function Get_First_CPU returns the first CPU in Domain, or CPU'First
if Domain is empty; Get_Last_CPU returns the last CPU in Domain, or
CPU_Range'First if Domain is empty. The function Get_CPU_Set(D) returns an
array whose low bound is Get_First_CPU(D), whose high bound is
Get_Last_CPU(D), with True values in the Set corresponding to the CPUs that
are in the given Domain.
25/4 The function Get_Dispatching_Domain returns the dispatching domain on
which the task is assigned.
26/4 A call of the procedure Assign_Task assigns task T to the CPU within the
dispatching domain Domain. Task T can now execute only on CPU, unless CPU
designates Not_A_Specific_CPU in which case it can execute on any processor
within Domain. The exception Dispatching_Domain_Error is propagated if Domain
is empty, T is already assigned to a dispatching domain other than
System_Dispatching_Domain, or if CPU is not one of the processors of Domain
(and is not Not_A_Specific_CPU). A call of Assign_Task is a task dispatching
point for task T unless T is inside of a protected action, in which case the
effect on task T is delayed until its next task dispatching point. If T is the
Current_Task the effect is immediate if T is not inside a protected action,
otherwise the effect is as soon as practical. Assigning a task already
assigned to System_Dispatching_Domain to that domain has no effect.
27/4 A call of procedure Set_CPU assigns task T to the CPU. Task T can now
execute only on CPU, unless CPU designates Not_A_Specific_CPU, in which case
it can execute on any processor within its dispatching domain. The exception
Dispatching_Domain_Error is propagated if CPU is not one of the processors of
the dispatching domain on which T is assigned (and is not Not_A_Specific_CPU).
A call of Set_CPU is a task dispatching point for task T unless T is inside of
a protected action, in which case the effect on task T is delayed until its
next task dispatching point. If T is the Current_Task the effect is immediate
if T is not inside a protected action, otherwise the effect is as soon as
practical.
28/3 The function Get_CPU returns the processor assigned to task T, or
Not_A_Specific_CPU if the task is not assigned to a processor.
29/4 A call of Delay_Until_And_Set_CPU delays the calling task for the
designated time and then assigns the task to the specified processor when the
delay expires. The exception Dispatching_Domain_Error is propagated if P is
not one of the processors of the calling task's dispatching domain (and is not
Not_A_Specific_CPU).
Implementation Requirements
30/3 The implementation shall perform the operations Assign_Task, Set_CPU,
Get_CPU and Delay_Until_And_Set_CPU atomically with respect to any of these
operations on the same dispatching_domain, processor or task.
30.1/4 Any task that belongs to the system dispatching domain can execute on
any CPU within that domain, unless the assignment of the task has been
specified.
Implementation Advice
31/3 Each dispatching domain should have separate and disjoint ready queues.
Documentation Requirements
32/3 The implementation shall document the processor(s) on which the clock
interrupt is handled and hence where delay queue and ready queue manipulations
occur. For any Interrupt_Id whose handler can execute on more than one
processor the implementation shall also document this set of processors.
Implementation Permissions
33/3 An implementation may limit the number of dispatching domains that can be
created and raise Dispatching_Domain_Error if an attempt is made to exceed
this number.
Generated by dwww version 1.15 on Tue Jun 25 08:45:37 CEST 2024.