CVS difference for arm/source/rt.mss

Differences between 1.16 and version 1.17
Log of other versions for file arm/source/rt.mss

--- arm/source/rt.mss	2000/08/11 00:09:16	1.16
+++ arm/source/rt.mss	2000/08/15 01:11:45	1.17
@@ -1,7 +1,7 @@
 @Comment{ $Source: e:\\cvsroot/ARM/Source/rt.mss,v $ }
-@comment{ $Revision: 1.16 $ $Date: 2000/08/11 00:09:16 $ $Author: Randy $ }
+@comment{ $Revision: 1.17 $ $Date: 2000/08/15 01:11:45 $ $Author: Randy $ }
 @Part(realtime, Root="ada.mss")
-@Comment{$Date: 2000/08/11 00:09:16 $}
+@Comment{$Date: 2000/08/15 01:11:45 $}
 
 @LabeledNormativeAnnex{Real-Time Systems}
 
@@ -9,7 +9,7 @@
 @Defn{real-time systems}
 @Defn{embedded systems}
 This Annex specifies additional characteristics of Ada implementations
-intended for real-time systems software.  To conform to this Annex, an
+intended for real-time systems software. To conform to this Annex, an
 implementation shall also conform to the Systems Programming Annex.
 @end{Intro}
 
@@ -38,7 +38,7 @@
 the implementation shall report that the metric is unbounded.
 @begin{Discussion}
 There are several good reasons to specify metrics in seconds; there are however
-equally good reasons to specify them in processor clock cycles.  In
+equally good reasons to specify them in processor clock cycles. In
 defining the metrics, we have tried to strike a balance on a case-by-case
 basis.
 
@@ -53,10 +53,10 @@
 @begin{Notes}
 
 The specification of the metrics makes a distinction between upper bounds
-and simple execution times.  Where something is just specified as @lquotes@;the
+and simple execution times. Where something is just specified as @lquotes@;the
 execution time of@rquotes@; a piece of code, this leaves one
 the freedom
-to choose a nonpathological case.  This kind of metric is of the form
+to choose a nonpathological case. This kind of metric is of the form
 @lquotes@;there exists a program such that the value of the metric is V@rquotes@;.
 Conversely, the meaning of upper bounds is @lquotes@;there is no program such
 that the value of the metric is greater than V@rquotes@;.
@@ -65,16 +65,16 @@
 
 The metrics do not cover the whole language;  they are limited
 to features that are specified in @RefSec{Systems Programming}
-and in this Annex.  The metrics are intended
+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
+particular real-time application. As such, the metrics are aimed
 at known implementation choices that can result in significant
 performance differences.
 
 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
+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
@@ -83,7 +83,7 @@
 @end{Notes}
 
 @begin{Extend83}
-This Annex is new to Ada 9X.
+This Annex is new to Ada 95.
 @end{Extend83}
 
 @LabeledClause{Task Priorities}
@@ -94,13 +94,13 @@
 
 @begin{Syntax}
 @begin{SyntaxText}
-The form of a @nt{pragma} Priority is as follows:
+@leading@keepnext@;The form of a @nt{pragma} Priority is as follows:
 @end{SyntaxText}
 
 @PragmaSyn`@key{pragma} @prag(Priority)(@Syn2{expression});'
 
 @begin{SyntaxText}
-The form of a @nt{pragma} Interrupt_Priority is as follows:
+@leading@keepnext@;The form of a @nt{pragma} Interrupt_Priority is as follows:
 @end{SyntaxText}
 
 @PragmaSyn`@key{pragma} @prag(Interrupt_Priority)[(@Syn2{expression})];'
@@ -120,7 +120,7 @@
 
 A Priority pragma is allowed only immediately within a @nt{task_definition},
 a @nt{protected_definition}, or the @nt{declarative_part} of a
-@nt{subprogram_body}.  An Interrupt_Priority pragma is allowed only
+@nt{subprogram_body}. An Interrupt_Priority pragma is allowed only
 immediately within a @nt{task_definition} or a @nt{protected_definition}.
 At most one such pragma shall appear within a given construct.
 
@@ -136,7 +136,7 @@
 
 @begin{StaticSem}
 
-The following declarations exist in package System:
+@leading@keepnext@;The following declarations exist in package System:
 @begin{example}
 @key{subtype} Any_Priority @key{is} Integer @key{range} @RI{implementation-defined};
 @key{subtype} Priority @key{is} Any_Priority @key{range} Any_Priority'First .. @RI{implementation-defined};
@@ -147,13 +147,13 @@
 @ImplDef{The declarations of Any_Priority and Priority.}
 
 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
+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.  @Redundant[The subrange of priority values below
+subtype Interrupt_Priority. @Redundant[The subrange of priority values below
 System.Interrupt_Priority'First is specified by the subtype System.Priority.]
 
 The priority specified by a Priority or Interrupt_Priority pragma is the
-value of the @nt{expression} in the pragma, if any.  If there is no
+value of the @nt{expression} in the pragma, if any. If there is no
 @nt{expression} in an Interrupt_Priority pragma, the priority value is
 Interrupt_Priority'Last.
 
@@ -172,13 +172,13 @@
 @Defn{active priority}
 A @i{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
+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 @i{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 @RefSecNum{Dynamic Priorities}).  At all times, a task also has
+(see @RefSecNum{Dynamic Priorities}). At all times, a task also has
 an @i{active priority}, which generally reflects its base priority
 as well as any priority it inherits from other sources.
 @i{Priority inheritance} is the process by which the priority of a
@@ -222,14 +222,14 @@
 to determine the task's position in any queue when Priority_Queuing is
 specified (see @RefSecNum{Entry Queuing Policies}).]
 
-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
+@Leading@;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 @RefSecNum{Asynchronous Task Control}), its base priority is always
-a source of priority inheritance.  Other sources of priority inheritance
+a source of priority inheritance. Other sources of priority inheritance
 are specified under the following
 conditions:
 @begin{Discussion}
-Other parts of the annex, e.g.  @RefSecNum{Asynchronous Task Control}, define
+Other parts of the annex, e.g. @RefSecNum{Asynchronous Task Control}, define
 other sources of priority inheritance.
 @end{Discussion}
 @begin{itemize}
@@ -267,7 +267,7 @@
 
 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
+is re-evaluated. This is in addition to other instances described in this
 Annex for such re-evaluation.
 
 An implementation may provide a non-standard mode in which tasks
@@ -331,7 +331,7 @@
 @RootDefn{task dispatching point}
 @RootDefn{dispatching point}
 @i{Task dispatching} is the process by which one ready task is selected
-for execution on a processor.  This selection is done at certain points
+for execution on a processor. This selection is done at certain points
 during the execution of a task called @i{task dispatching
 points}.
 A task reaches a task dispatching point whenever it becomes blocked,
@@ -360,7 +360,7 @@
 @i{tail of the queue}.
 A task is @i{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 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
@@ -369,7 +369,7 @@
 A task can be on the ready queues of more than one processor.
 @begin{Discussion}
 The core language defines a ready task as one that is not
-blocked.  Here we refine this definition and
+blocked. Here we refine this definition and
 talk about ready queues.
 @end{Discussion}
 
@@ -398,7 +398,7 @@
 @begin{Reason}
 A processor that is executing a task is available to execute tasks of
 higher priority, within the set of tasks that that processor is able to
-execute.  Write access to a protected object, on the
+execute. Write access to a protected object, on the
 other hand, cannot be granted to a new task before the
 old task has released it.
 @end{Reason}
@@ -463,12 +463,12 @@
 The ready queues are purely conceptual; there is no requirement that such
 lists physically exist in an implementation.
 
-While a task is running, it is not on any ready queue.  Any time
+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.
 
 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
+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.
@@ -486,7 +486,7 @@
 
 @begin{Syntax}
 @begin{SyntaxText}
-The form of a @nt{pragma} Task_Dispatching_Policy is as follows:
+@Leading@Keepnext@;The form of a @nt{pragma} Task_Dispatching_Policy is as follows:
 @end{SyntaxText}
 
 @PragmaSyn`@key{pragma} @prag(Task_Dispatching_Policy)(@SynI{policy_}@Syn2{identifier} );'
@@ -528,7 +528,7 @@
 units comprising a partition, the task dispatching policy for
 that partition is unspecified.
 
-The language defines only one task dispatching policy, FIFO_Within_Priorities;
+@Leading@;The language defines only one task dispatching policy, FIFO_Within_Priorities;
 when this policy is in effect, modifications to the ready queues occur
 only as follows:
 @begin{itemize}
@@ -569,10 +569,10 @@
 
 @begin{DocReq}
 
-@Defn{priority inversion}
+@Leading@Defn{priority inversion}
 @i{Priority inversion} is the duration for which a task remains at the
 head of the highest priority ready queue while the processor executes
-a lower priority task.  The implementation shall document:
+a lower priority task. The implementation shall document:
 @begin{Itemize}
 The maximum priority inversion a user task can experience due to activity
 of the implementation (on behalf of lower priority tasks), and
@@ -612,7 +612,7 @@
 
 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
+is called. The effect of setting the task's base priority is deferred
 while the affected task performs a protected action.
 
 Setting the base priority of a ready task causes
@@ -625,13 +625,13 @@
 
 @begin{Intro}
 @Redundant[This clause specifies the interactions between priority task
-scheduling and protected object ceilings.  This interaction is based on
+scheduling and protected object ceilings. This interaction is based on
 the concept of the @i{ceiling priority} of a protected object.]
 @end{Intro}
 
 @begin{Syntax}
 @begin{SyntaxText}
-The form of a @nt{pragma} Locking_Policy is as follows:
+@Leading@Keepnext@;The form of a @nt{pragma} Locking_Policy is as follows:
 @end{SyntaxText}
 
 @PragmaSyn`@key{pragma} @prag(Locking_Policy)(@SynI{policy_}@Syn2{identifier});'
@@ -658,12 +658,12 @@
 
 @Defn{locking policy}
 @Redundant[A locking policy specifies the details of protected object
-locking.  These rules specify whether or not protected objects have
+locking. These rules specify whether or not protected objects have
 priorities, and the relationships between these priorities and
-task priorities.  In addition, the policy specifies the state of a task
+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 @i{locking policy} is specified by a Locking_Policy pragma.  For
+The @i{locking policy} is specified by a Locking_Policy pragma. For
 implementation-defined locking policies, the effect of a Priority or
 Interrupt_Priority pragma on a protected object is
 implementation defined.
@@ -672,7 +672,7 @@
 of specifying either a Priority or Interrupt_Priority pragma for a
 protected object, are implementation defined.
 
-There is one predefined locking policy, Ceiling_Locking; this policy is
+@Leading@;There is one predefined locking policy, Ceiling_Locking; this policy is
 defined as follows:
 @begin{itemize}
 
@@ -779,7 +779,7 @@
 
 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
+protected actions of that object execute. In the extreme, if
 the ceiling is Interrupt_Priority'Last, all blockable interrupts
 are blocked during that time.
 
@@ -790,7 +790,7 @@
 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
+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
@@ -813,14 +813,14 @@
 @begin{Intro}
 @Redundant[@Defn{queuing policy}
 This clause specifies a mechanism for a user to choose an entry
-@i{queuing policy}.  It also defines one such policy.  Other
+@i{queuing policy}. It also defines one such policy. Other
 policies are implementation defined.]
 @ImplDef{Implementation-defined queuing policies.}
 @end{Intro}
 
 @begin{Syntax}
 @begin{SyntaxText}
-The form of a @nt{pragma} Queuing_Policy is as follows:
+@Leading@Keepnext@;The form of a @nt{pragma} Queuing_Policy is as follows:
 @end{SyntaxText}
 
 @PragmaSyn`@key{pragma} @prag(Queuing_Policy)(@SynI{policy_}@Syn2{identifier});'
@@ -856,21 +856,21 @@
 @end{Ramification}
 
 Two queuing policies, FIFO_Queuing and Priority_Queuing,
-are language defined.  If no Queuing_Policy pragma appears
+are language defined. If no Queuing_Policy pragma appears
 in 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
+is FIFO_Queuing. The rules for this policy are specified in
 @RefSecNum{Entry Calls} and @RefSecNum{Selective Accept}.
 
-The Priority_Queuing policy is defined as follows:
+@Leading@Keepnext@;The Priority_Queuing policy is defined as follows:
 @begin{itemize}
 
 @Defn{priority of an entry call}
 The calls to an entry @Redundant[(including a member of an entry family)]
-are queued in an order consistent with the priorities of the calls.  The
+are queued in an order consistent with the priorities of the calls. The
 @i{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 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).
 
@@ -910,23 +910,23 @@
 
 Furthermore, when an entry is used for @nt{asynchronous_select}s,
 it is almost certain to be a @lquotes@;broadcast@rquotes@; entry or have
-only one caller at a time.  For example, if the entry is
+only one caller at a time. For example, if the entry is
 used to notify tasks of a mode switch, then all tasks on the
-entry queue would be signaled when the mode changes.  Similarly,
+entry queue would be signaled when the mode changes. Similarly,
 if it is indicating some interrupting event such as a control-C,
 all tasks sensitive to the interrupt will want to be informed
-that the event occurred.  Hence, the order on such a queue is
+that the event occurred. Hence, the order on such a queue is
 essentially irrelevant.
 
 Given the above, it seems an unnecessary semantic and implementation
 complexity to specify that asynchronous queued calls are moved in
-response to dynamic priority changes.  Furthermore, it is somewhat
+response to dynamic priority changes. Furthermore, it is somewhat
 inconsistent, since the call was originally queued based on the active
 priority of the task, but dynamic priority changes are changing the base
-priority of the task, and only indirectly the active priority.  We say
+priority of the task, and only indirectly the active priority. We say
 explicitly that asynchronous queued calls are not affected by normal
 changes in active priority during the execution of an
-@nt{abortable_part}.  Saying that, if a change in the base priority
+@nt{abortable_part}. Saying that, if a change in the base priority
 affects the active priority, then we do want the calls reordered, would
 be inconsistent.
 It would also require the implementation to maintain a readily
@@ -942,10 +942,10 @@
 
 When more than one @nt{condition} of an @nt{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
+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 @nt{protected_definition} is
-selected.  For members of the same entry family,
+selected. For members of the same entry family,
 the one with the lower family index is selected.
 
 If the expiration time of two or more open
@@ -989,8 +989,7 @@
 @end{Intro}
 
 @begin{StaticSem}
-
-The following language-defined library package exists:
+@Leading@Keepnext@;The following language-defined library package exists:
 @begin{Example}
 @key[with] System;
 @key[with] Ada.Task_Identification; @RI{-- See @RefSecNum[The Package Task_Identification]}
@@ -1060,7 +1059,7 @@
 which might have a call queued on a protected object with a low ceiling.
 @end{ImplNote}
 @begin{Reason}
-A previous version of Ada 9X made it a run-time error
+@Leading@;A previous version of Ada 9X made it a run-time error
 for a high-priority task to set the priority of a lower-priority
 task that has a queued call on a protected object with a low ceiling.
 This was changed because:
@@ -1073,7 +1072,7 @@
 
 The run-time check would tend to cause intermittent system failures @em
 how is the caller supposed to know whether the other task happens to
-have a queued call at any given time?  Consider for example an
+have a queued call at any given time? Consider for example an
 interrupt that needs to trigger a priority change in some task.
 The interrupt handler could not safely call Set_Priority without knowing
 exactly what the other task is doing,
@@ -1137,10 +1136,10 @@
 @end{Erron}
 
 @begin{Metrics}
-The implementation shall document the following metric:
+@Leading@;The implementation shall document the following metric:
 @begin{Itemize}
 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
+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
@@ -1151,15 +1150,15 @@
 
 @begin{Notes}
 
-Setting a task's base priority affects task dispatching.  First, it can
-change the task's active priority.  Second, under the standard
+Setting a task's base priority affects task dispatching. First, it can
+change the task's active priority. Second, under the standard
 task dispatching 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.
 
 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
+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
@@ -1180,12 +1179,12 @@
 
 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 @RefSecNum{Entry Calls}).  In particular, setting or
+entry call (see @RefSecNum{Entry Calls}). In particular, setting or
 querying the priority of a completed or an abnormal
 task is allowed, so long as the task is not yet terminated.
 
 Changing the priorities of a set of tasks can be performed by a
-series of calls to Set_Priority for each task separately.  For
+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
@@ -1218,12 +1217,12 @@
 @end{DocReq}
 
 @begin{Metrics}
-The implementation shall document the following metrics:
+@Leading@;The implementation shall document the following metrics:
 @begin{Itemize}
 The execution time, in processor clock cycles, that it takes for an
 @nt{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
+and aborts T1. T1 does not have any finalization code. T2 shall
 verify that T1 has terminated, by means of the Terminated attribute.
 
 On a multiprocessor, an upper bound in seconds,
@@ -1231,23 +1230,23 @@
 the point that it is required for a single processor.
 
 An upper bound on the execution time of an
-@nt{asynchronous_select}, in processor clock cycles.  This is measured
+@nt{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 @nt{condition}
 of an @nt{entry_barrier} Pr.Wait true, and the point where task T2 resumes
 execution immediately after an entry call to Pr.Wait in an
-@nt{asynchronous_select}.  T1 preempts T2 while
+@nt{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,
+T2 can execute. The execution time of T1 is measured separately,
 and subtracted.
 
 An upper bound on the execution time of an
 @nt{asynchronous_select},
 in the case that no asynchronous transfer of control takes
-place.  This is measured between a point immediately before a task
+place. This is measured between a point immediately before a task
 executes the @nt{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.
+it. The execution time of the abortable part is subtracted.
 @end{Itemize}
 @end{Metrics}
 
@@ -1286,7 +1285,7 @@
 @end{Intro}
 
 @begin{StaticSem}
-The following @SynI{restriction_}@nt{identifier}s are language defined:
+@Leading@;The following @SynI{restriction_}@nt{identifier}s are language defined:
 @begin{Description}
 @Defn2{Term=[Restrictions],Sec=(No_Task_Hierarchy)}No_Task_Hierarchy @\All (nonenvironment) tasks depend directly on
                         the environment task of the partition.
@@ -1311,7 +1310,7 @@
 
 @Defn2{Term=[Restrictions],Sec=(No_Implicit_Heap_Allocations)}No_Implicit_Heap_Allocations @\There are no operations that implicitly require
                         heap storage allocation to be performed by the
-                        implementation.  The operations that implicitly
+                        implementation. The operations that implicitly
                         require heap storage allocation are
                         implementation defined.
 @ImplDef{Any operations that implicitly
@@ -1325,7 +1324,7 @@
                 Asynchronous_Task_Control.
 @end{Description}
 
-The following @SynI{restriction_parameter_}@nt{identifier}s are
+@Leading@;The following @SynI{restriction_parameter_}@nt{identifier}s are
 language defined:
 @begin{Description}
 @Defn2{Term=[Restrictions],Sec=(Max_Select_Alternatives)}Max_Select_Alternatives @\Specifies the maximum number of alternatives
@@ -1358,7 +1357,7 @@
 If an implementation chooses to detect such a violation,
 Storage_Error should be raised.
 
-The following @SynI{restriction_parameter_}@nt{identifier}s are
+@Leading@;The following @SynI{restriction_parameter_}@nt{identifier}s are
 language defined:
 @begin{Description}
 @Defn2{Term=[Restrictions],Sec=(Max_Storage_At_Blocking)}Max_Storage_At_Blocking @\Specifies the maximum portion
@@ -1393,7 +1392,7 @@
 
 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
+or execution time. If possible, the implementation should provide
 quantitative descriptions of such effects for each restriction.
 @ImplDef{Implementation-defined aspects of pragma Restrictions.}
 
@@ -1415,7 +1414,7 @@
 @end{Intro}
 
 @begin{StaticSem}
-The following language-defined library package exists:
+@Leading@;The following language-defined library package exists:
 @begin{example}
 @ChildUnit{Parent=[Ada],Child=[Real_Time]}
 @key[package] Ada.Real_Time @key[is]
@@ -1497,15 +1496,15 @@
 @Redundant[values of this type may be used in a
 @nt{delay_until_statement}.]
 Values of this type
-represent segments of an ideal time line.  The set of values of
+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.
 @begin{Discussion}
 Informally, real time is defined to be the International Atomic Time (TAI)
-which is monotonic and nondecreasing.  We use it here for the purpose of
-discussing rate of change and monotonic behavior only.  It does not imply
+which is monotonic and nondecreasing. We use it here for the purpose of
+discussing rate of change and monotonic behavior only. It does not imply
 anything about the absolute value of Real_Time.Clock, or about Real_Time.Time
-being synchronized with TAI.  It is also used for real time in the metrics,
+being synchronized with TAI. It is also used for real time in the metrics,
 for comparison purposes.
 @end{Discussion}
 @begin{ImplNote}
@@ -1561,18 +1560,18 @@
 @begin{RunTime}
 
 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
+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.
 @Defn{clock tick}
 A @i{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.
+constant. Tick is the average length of such intervals.
 
 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 both operations, the result is
+Duration. Similarly, the function To_Time_Span converts the value D
+to a value of type Time_Span. For both operations, the result is
 rounded to the nearest exactly representable value (away from zero if exactly
 halfway between two exactly representable values).
 
@@ -1580,7 +1579,7 @@
 and To_Time_Span(0.0) returns Time_Span_Zero.
 
 The functions Nanoseconds, Microseconds, and Milliseconds convert the input
-parameter to a value of the type Time_Span.  NS, US,
+parameter to a value of the type Time_Span. NS, US,
 and MS are interpreted as a number of nanoseconds, microseconds, and
 milliseconds respectively.
 The result is rounded to the nearest exactly
@@ -1632,7 +1631,7 @@
 
 @Defn{clock jump}
 A @i{clock jump} is the difference between two successive distinct values of
-the clock (as observed by calling the Clock function).  There shall be no
+the clock (as observed by calling the Clock function). There shall be no
 backward clock jumps.
 
 @end{ImplReq}
@@ -1677,9 +1676,9 @@
 For the purpose of the metrics defined in this clause, real time is
 defined to be the International Atomic Time (TAI).
 
-The implementation shall document the following metrics:
+@Leading@;The implementation shall document the following metrics:
 @begin{Itemize}
-An upper bound on the real-time duration of a clock tick.  This is a value
+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 @en@; t1 <= D.
 
@@ -1694,13 +1693,13 @@
 @end{display}
 
 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
+time duration not less than 24 hours. The value of E used for
 this metric shall be reported.
 @begin{Reason}
 This metric is intended to provide a measurement
 of the long term (cumulative) deviation; therefore, 24
 hours is the
-lower bound on the measurement period.  On some implementations,
+lower bound on the measurement period. On some implementations,
 this is also the maximum period, since the language does not
 require that the range of the type Duration be more than 24 hours.
 On those implementations that support longer-range Duration, longer
@@ -1759,7 +1758,7 @@
 
 It is recommended that the @lquotes@;best@rquotes@; time base which exists in the
 underlying system be available to the application through
-Clock.  @lquotes@;Best@rquotes@; may mean highest accuracy or largest range.
+Clock. @lquotes@;Best@rquotes@; may mean highest accuracy or largest range.
 
 @end{ImplAdvice}
 
@@ -1769,7 +1768,7 @@
 the user from operator or installation errors which could result in the
 clock being set incorrectly.
 
-Time_Unit is the granularity of the Time type.  In contrast,
+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.
 
@@ -1781,14 +1780,14 @@
 @Redundant[This clause specifies performance requirements for the
 @nt{delay_statement}.
 The rules apply both to @nt{delay_relative_statement} and to
-@nt{delay_until_statement}.  Similarly, they apply equally to a
+@nt{delay_until_statement}. Similarly, they apply equally to a
 simple @nt{delay_statement} and to one which appears in a
 @nt{delay_alternative}.]
 @end{Intro}
 
 @begin{RunTime}
-The effect of the @nt{delay_statement} for Real_Time.Time is defined in
-terms of Real_Time.Clock:
+@Leading@;The effect of the @nt{delay_statement} for Real_Time.Time is
+defined in terms of Real_Time.Clock:
 @begin{itemize}
 
 If C@-{1} is a value of Clock read before a task executes a
@@ -1812,7 +1811,7 @@
 regardless of the specified expiration time.
 @begin{Ramification}
 The effect of these requirements is that one has to always attempt a rendezvous,
-regardless of the value of the delay expression.  This can be tested by
+regardless of the value of the delay expression. This can be tested by
 issuing a @nt{timed_entry_call} with an expiration time
 of zero, to an open entry.
 @end{Ramification}
@@ -1835,7 +1834,7 @@
 @end{DocReq}
 
 @begin{Metrics}
-The implementation shall document the following metrics:
+@Leading@;The implementation shall document the following metrics:
 @begin{Itemize}
 An upper bound on the execution time, in processor clock cycles, of a
 @nt{delay_relative_statement} whose requested value of the delay expression
@@ -1844,7 +1843,7 @@
 An upper bound on the execution time, in processor clock cycles, of a
 @nt{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.
+time of executing the statement. Similarly, for Calendar.Clock.
 
 @Defn{lateness}
 @Defn{actual duration}
@@ -1852,10 +1851,10 @@
 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
+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 @i{actual duration}.  The actual duration is measured from a point
+from the @i{actual duration}. The actual duration is measured from a point
 immediately before a task executes the @nt{delay_statement} to a point
 immediately after the task resumes execution following this statement.
 
@@ -1863,10 +1862,10 @@
 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
+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 @nt{delay_until_statement} is obtained by
+execution. The lateness of a @nt{delay_until_statement} is obtained by
 subtracting the requested expiration time from the real time that the task
 resumes execution following this statement.
 @end{Itemize}
@@ -1900,7 +1899,7 @@
 
 @begin{StaticSem}
 
-The following language-defined package exists:
+@Leading@;The following language-defined package exists:
 @begin{example}
 @ChildUnit{Parent=[Ada],Child=[Synchronous_Task_Control]}
 @key{package} Ada.Synchronous_Task_Control @key{is}
@@ -1926,11 +1925,11 @@
 @begin{RunTime}
 
 An object of the type Suspension_Object has two visible states: true and
-false.  Upon initialization, its value is set to false.
+false. Upon initialization, its value is set to false.
 @begin{Discussion}
 This object is assumed to be private to the declaring task, i.e. only that
 task will call Suspend_Until_True on this object, and the count of callers is
-at most one.  Other tasks can, of course, change and query the state of this
+at most one. Other tasks can, of course, change and query the state of this
 object.
 @end{Discussion}
 
@@ -1975,7 +1974,7 @@
 
 @begin{StaticSem}
 
-The following language-defined library package exists:
+@Leading@;The following language-defined library package exists:
 @begin{example}
 @key{with} Ada.Task_Identification;
 @ChildUnit{parent=[Ada],Child=[Asynchronous_Task_Control]}
@@ -2001,12 +2000,12 @@
 in @RefSecNum{Task Execution - Task Activation}; the task is still ready.
 @end{Discussion}
 For each processor there is a conceptual @i{idle task},
-which is always ready.  The base priority of the idle task is below
-System.Any_Priority'First.  The @i{held priority} is a
+which is always ready. The base priority of the idle task is below
+System.Any_Priority'First. The @i{held priority} is a
 constant of the type integer whose value is below the base priority of the
 idle task.
 
-The Hold operation sets the state of T to held.  For a held task:
+The Hold operation sets the state of T to held. For a held task:
 the task's own base priority does not constitute an inheritance source
 (see @RefSecNum{Task Priorities}), and the value of the held priority
 is defined to be such a source instead.
@@ -2075,7 +2074,7 @@
 
 Calling Hold on a held task or Continue on a non-held task has no effect.
 
-The rules affecting queuing are derived from the above rules, in
+@Leading@;The rules affecting queuing are derived from the above rules, in
 addition to the normal priority rules:
 @begin{itemize}
 
@@ -2083,7 +2082,7 @@
 reach the top of the queue as long as there are other tasks on that queue.
 
 If a task is executing in a protected action, inside a rendezvous, or is
-inheriting priorities from other sources (e.g.  when activated), it
+inheriting priorities from other sources (e.g. when activated), it
 continues to execute until it is no longer executing the corresponding
 construct.
 
@@ -2092,13 +2091,13 @@
 
 If a task becomes held while waiting in a @nt{selective_accept},
 and a entry call is issued to one of the open entries, the corresponding
-accept body executes.  When the rendezvous completes, the active
+accept body 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.
 
 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.
+whose barrier becomes open. The corresponding entry body executes.
 
 @end{itemize}
 
@@ -2136,7 +2135,7 @@
 
 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
+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.
 
@@ -2146,7 +2145,7 @@
 
 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
+implementation. If this is different for different interrupts or
 interrupt priority levels, it should be documented for each case.
 @ImplDef{The upper bound on the duration of interrupt blocking caused by
 the implementation.}
@@ -2154,13 +2153,13 @@
 @end{DocReq}
 
 @begin{Metrics}
-The implementation shall document the following metric:
+@Leading@;The implementation shall document the following metric:
 @begin{Itemize}
 The overhead associated with obtaining
-a mutual-exclusive access to an entry-less protected object.  This shall be
+a mutual-exclusive access to an entry-less protected object. This shall be
 measured in the following way:
 
-@NoPrefix@;For a protected object of the form:
+@NoPrefix@Leading@;For a protected object of the form:
 @begin{example}
 @key{protected} Lock @key{is}
    @key{procedure} Set;
@@ -2186,10 +2185,10 @@
 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
+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
+period. The protected object shall have sufficiently high ceiling priority
 to allow the task to call Set.
 
 @NoPrefix@;For a multiprocessor, if supported, the metric shall be reported for the

Questions? Ask the ACAA Technical Agent