Go to the first, previous, next, last section, table of contents.
-
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
-
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.
-
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
-
(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.
-
(2) The metrics do not cover the whole language; they are limited to
features that are specified in Annex See section C Systems Programming (normative),
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.
-
(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
- D.2: Priority Scheduling
- D.3: Priority Ceiling Locking
- D.4: Entry Queuing Policies
- D.5: Dynamic Priorities
- D.6: Preemptive Abort
- D.7: Tasking Restrictions
- D.8: Monotonic Time
- D.9: Delay Accuracy
- D.10: Synchronous Task Control
- D.11: Asynchronous Task Control
- D.12: Other Optimizations and Determinism Rules
--- The Detailed Node Listing ---
- D.1: Task Priorities
- D.2: Priority Scheduling
- D.2.1: The Task Dispatching Model
- D.2.2: The Standard Task Dispatching Policy
- D.3: Priority Ceiling Locking
- D.4: Entry Queuing Policies
- D.5: Dynamic Priorities
- D.6: Preemptive Abort
- D.7: Tasking Restrictions
- D.8: Monotonic Time
- D.9: Delay Accuracy
- D.10: Synchronous Task Control
- D.11: Asynchronous Task Control
- D.12: Other Optimizations and Determinism Rules
Go to the first, previous, next, last section, table of contents.