Go to the first, previous, next, last section, table of contents.


Real-Time Systems (normative)

  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 See section 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.
  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.

Task Priorities

  1. This clause specifies the priority model for real-time systems. In addition, the methods for specifying priorities are defined. Syntax
  2. The form of a pragma Priority is as follows:
  3. pragma Priority(expression);
    
  4. The form of a pragma Interrupt_Priority is as follows:
  5. pragma Interrupt_Priority[(expression)];
    
    Name Resolution Rules
  6. The expected type for the expression in a Priority or Interrupt_Priority pragma is Integer. Legality Rules
  7. A Priority pragma is allowed only immediately within a task_definition, a protected_definition, or the declarative_part of a subprogram_body. An Interrupt_Priority pragma is allowed only immediately within a task_ definition or a protected_definition. At most one such pragma shall appear within a given construct.
  8. For a Priority pragma that appears in the declarative_part of a subprogram_body, the expression shall be static, and its value shall be in the range of System.Priority. 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. The priority specified by a Priority or Interrupt_Priority pragma is the value of the expression in the pragma, if any. If there is no expression in an Interrupt_Priority pragma, the priority value is Interrupt_Priority'Last. Dynamic Semantics
  14. A Priority pragma has no effect if it occurs in the declarative_part of the subprogram_body of a subprogram other than the main subprogram.
  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 section Dynamic Priorities. 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 section Priority Ceiling Locking.) is used in the evaluation of another task's active priority.
  16. The effect of specifying such a pragma in a protected_definition is discussed in section Priority Ceiling Locking.
  17. The expression in a Priority or Interrupt_Priority pragma that appears in a task_definition is evaluated for each task object, see section Task Units and Task Objects. For a Priority pragma, the value of the expression is converted to the subtype Priority; for an Interrupt_Priority pragma, this value is converted to the subtype Any_Priority. The priority value is then associated with the task object whose task_definition contains the pragma.
  18. Likewise, the priority value is associated with the environment task if the pragma appears in the declarative_part of the main subprogram.
  19. The initial value of a task's base priority is specified by default or by means of a Priority or Interrupt_Priority pragma. After a task is created, its base priority can be changed only by a call to Dynamic_Priorities.Set_Priority, see section Dynamic Priorities. The initial base priority of a task in the absence of a pragma is the base priority of the task that creates it at the time of creation, see section Task Units and Task Objects. If a pragma Priority does not apply to 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 section Entry Queuing Policies.
  20. 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 section Asynchronous Task Control, its base priority is always a source of priority inheritance. Other sources of priority inheritance are specified under the following conditions:
    1. During activation, a task being activated inherits the active priority of the its activator, see section Task Execution - Task Activation.
    2. During rendezvous, the task accepting the entry call inherits the active priority of the caller, see section Entry Calls.
    3. During a protected action on a protected object, a task inherits the ceiling priority of the protected object, see section Intertask Communication, and section Priority Ceiling Locking.
  1. 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
  2. The range of System.Interrupt_Priority shall include at least one value.
  3. The range of System.Priority shall include at least 30 values. NOTES
  4. (4) The priority expression can include references to discriminants of the enclosing type.
  5. (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.
  6. (6) An implementation may provide a non-standard mode in which tasks inherit priorities under conditions other than those specified above.

Priority Scheduling

  1. This clause describes the rules that determine which task is selected for execution when more than one task is ready, see section Task Execution - Task Activation. The rules have two parts: the task dispatching model, see section The Task Dispatching Model, and a specific task dispatching policy, see section The Standard Task Dispatching Policy.

The Task Dispatching Model

  1. The task dispatching model specifies preemptive scheduling, based on conceptual priority-ordered ready queues. Dynamic Semantics
  2. A task runs (that is, it becomes a running task) only when it is ready, See section Task Execution - Task Activation, 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. 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 whenever it becomes ready. In addition, the completion of an accept_statement, see section Entries and Accept Statements, and task termination are task dispatching points for the executing task. Other task dispatching points are defined throughout this Annex.
  5. Task dispatching policies are specified in terms of conceptual ready queues, task states, and task preemption. 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. 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, one task is 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. A preemptible resource is a resource that while allocated to one task can be allocated (temporarily) to another instead. Processors are preemptible resources. Access to a protected object, see section Protected Subprograms and Protected Actions, is a nonpreemptible resource. When a higher-priority task is dispatched to the processor, and the previously running task is placed on the appropriate ready queue, the latter task is said to be preempted.
  8. A new running task is also selected whenever there is a nonempty ready queue with a higher priority than the priority of the running task, or when the task dispatching policy requires a running task to go back to a ready queue. These are also task dispatching points. Implementation Permissions
  9. 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, see section The Standard Task Dispatching Policy.
  10. An implementation may place implementation-defined restrictions on tasks whose active priority is in the Interrupt_Priority range. NOTES
  11. (7) Section section Tasks and Synchronization 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 See section Task Priorities, see section Priority Ceiling Locking, and section Dynamic Priorities.

The Standard Task Dispatching Policy

Syntax

  1. The form of a pragma Task_Dispatching_Policy is as follows:
  2. pragma Task_Dispatching_Policy(policy_identifier );
    
    Legality Rules
  3. The policy_identifier shall either be FIFO_Within_Priorities or an implementation-defined identifier. Post-Compilation Rules
  4. A Task_Dispatching_Policy pragma is a configuration pragma.
  5. If the FIFO_Within_Priorities policy is specified for a partition, then the Ceiling_Locking policy, see section Priority Ceiling Locking shall also be specified for the partition. Dynamic Semantics
  6. 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, and whether a task is inserted at the head or the tail of the queue for its active priority. The task dispatching policy is specified by a Task_Dispatching_Policy configuration pragma. If no such pragma appears in any of the program units comprising a partition, the task dispatching policy for that partition is unspecified.
  7. 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:
    1. When a blocked task becomes ready, it is added at the tail of the ready queue for its active priority.
    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.
    3. 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.
    4. 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.
  1. Each of the events specified above is a task dispatching point, See section The Task Dispatching Model.
  2. In addition, when a task is preempted, it is added at the head of the ready queue for its active priority. Documentation Requirements
  3. 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:
    1. The maximum priority inversion a user task can experience due to activity of the implementation (on behalf of lower priority tasks), and
    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.

Implementation Permissions

  1. Implementations are allowed to define other task dispatching policies, but need not support more than one such policy per partition.
  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
  3. (13) 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).
  4. (14) 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.
  5. (15) Setting the base priority of a ready task causes the task to move to the end of the queue for its active priority, regardless of whether the active priority of the task actually changes.

Priority Ceiling Locking

  1. This clause 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. A locking policy specifies the details of protected object 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 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 effect of a Priority or Interrupt_Priority pragma on a protected object is implementation defined. If no Locking_Policy pragma appears in any of the program units comprising a partition, the locking policy for that partition, as well as the effect of specifying either a Priority or Interrupt_Priority pragma for a protected object, are implementation defined.
  7. There is one predefined locking policy, Ceiling_Locking; this policy is defined as follows:
    1. Every protected object has a ceiling priority, which is determined by either a Priority or Interrupt_Priority pragma as defined in D.1. 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.
    2. The expression of a Priority or Interrupt_Priority pragma 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 ceiling priority of the corresponding protected object.
    3. If an Interrupt_Handler or Attach_Handler pragma, see section Protected Procedure Handlers, appears in a protected_definition without an Interrupt_Priority pragma, the ceiling priority of protected objects of that type is implementation defined, but in the range of the subtype System.Interrupt_Priority.
    4. If no pragma Priority, Interrupt_Priority, Interrupt_Handler, or Attach_Handler is specified in the protected_definition, then the ceiling priority of the corresponding protected object is System.Priority'Last.
    5. While a task executes a protected action, it inherits the ceiling priority of the corresponding protected object.
    6. 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.

Implementation Permissions

  1. 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.
  2. Implementations are allowed to define other locking policies, but need not support more than one such policy per partition.
  3. Since implementations are allowed to place restrictions on code that runs at an interrupt-level active priority, see section Protected Procedure Handlers, and See section The Task Dispatching Model, 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
  4. The implementation should use names that end with "_Locking" for implementation-defined locking policies. NOTES
  5. (16) 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.
  6. (17) 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.
  7. (18) 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 section Interrupt Support.
  8. (19) 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.
  9. (20) 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 section Protected Procedure Handlers.
  10. (21) 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).

Entry Queuing Policies

  1. This clause specifies a mechanism for a user to choose an entry queuing policy. It also defines one such policy. 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. Two queuing policies, FIFO_Queuing and Priority_Queuing, 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 section Entry Calls, and section Selective Accept.
  8. The Priority_Queuing policy is defined as follows:
    1. 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).
    2. 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.
    3. When the base priority of a task is set, see section Dynamic Priorities, 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.
    4. 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.
    5. 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.
    6. 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

  1. Implementations are allowed to define other queuing policies, but need not support more than one such policy per partition. Implementation Advice
  2. The implementation should use names that end with "_Queuing" for implementation-defined queuing policies.

Dynamic Priorities

  1. This clause specifies 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. with System;
    with Ada.Task_Identification; --  see section The Package Task_Identification.
    package Ada.Dynamic_Priorities is
    
  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. Setting the task's base priority to the new value takes place as soon as is practical but not while the task is performing a protected action. This setting occurs no later then the next abort completion point of the task T, see section Abort of a Task - Abort of a Sequence of Statements. Bounded (Run-Time) Errors
  11. If a task is blocked on a protected entry call, and the call is queued, it is a bounded error to raise its base priority above the ceiling priority of the corresponding protected object. When an entry call is cancelled, it is a bounded error if the priority of the calling task is higher than the ceiling priority of the corresponding protected object. In either of these cases, either Program_Error is raised in the task that called the entry, or its priority is temporarily lowered, or both, or neither. 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. Metrics
  13. The implementation shall document the following metric:
    1. 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
  1. (22) 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.
  2. (23) 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 section Entry Queuing Policies, unless the call originated from the triggering_statement of an asynchronous_select.
  3. (24) 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.
  4. (25) 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 section 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.
  5. (26) 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.

Preemptive Abort

  1. This clause 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:
    1. 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.
    2. 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.
    3. 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.
    4. 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

  1. Even though the abort_statement is included in the list of potentially blocking operations, see section Protected Subprograms and Protected Actions, it is recommended that this statement be implemented in a way that never requires the task executing the abort_statement to block.
  2. 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
  3. (27) Abortion does not change the active or base priority of the aborted task.
  4. (28) Abortion cannot be more immediate than is allowed by the rules for deferral of abortion during finalization and in protected actions.

Tasking Restrictions

  1. This clause defines restrictions that can be used with a pragma Restrictions, see section Pragma Restrictions, to facilitate the construction of highly efficient tasking run-time systems. Static Semantics
  2. The following restriction_identifiers are language defined:
  3. No_Task_Hierarchy
    All (nonenvironment) tasks depend directly on the environment
    task of the partition.
    
  4. No_Nested_Finalization
    Objects with controlled parts and access types that designate
    such objects shall be declared only at library level.
    
  5. No_Abort_Statements
    There are no abort_statements, and there are no calls on
    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.
    
  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. No_Dynamic_Priorities
    There are no semantic dependences on the package
    Dynamic_Priorities.
    
  10. No_Asynchronous_Control
    There are no semantic dependences on the package
    Asynchronous_Task_Control.
    
  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. If the following restrictions are violated, the behavior is implementation defined. If an implementation chooses to detect such a violation, Storage_Error should be raised.
  16. The following restriction_parameter_identifiers are language defined:
  17. 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.
    
  18. Max_Asynchronous_Select_Nesting
    Specifies the maximum dynamic nesting level of
    asynchronous_selects. A value of zero prevents the use of any
    asynchronous_select.
    
  19. 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.
    
  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. (29) The above Storage_Checks can be suppressed with pragma Suppress.

Monotonic Time

  1. This clause 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;
    
  1.   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;
    
  2.   Tick : constant Time_Span;
      function Clock return Time;
    
  3.   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;
    
  4.   function "<" (Left, Right : Time) return Boolean;
      function "<="(Left, Right : Time) return Boolean;
      function ">" (Left, Right : Time) return Boolean;
      function ">="(Left, Right : Time) return Boolean;
    
  5.   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;
    
  6.   function "abs"(Right : Time_Span) return Time_Span;
    
  7.   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;
    
  8.   function To_Duration (TS : Time_Span) return Duration;
      function To_Time_Span (D : Duration) return Time_Span;
    
  9.   function Nanoseconds  (NS : Integer) return Time_Span;
      function Microseconds (US : Integer) return Time_Span;
      function Milliseconds (MS : Integer) return Time_Span;
    
  10.   type Seconds_Count is range implementation-defined;
    
  11.   procedure Split(T  : in     Time;
                      SC :    out Seconds_Count;
                      TS :    out Time_Span);
      function Time_Of(SC : Seconds_Count; TS : Time_Span) return Time;
    
  12. private
       ... -- not specified by the language
    end Ada.Real_Time;
    
  13. 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 See section Delay Statements, Duration, and Time, 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.
  14. 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.
  15. 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.
  16. 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.
  17. A value of type Seconds_Count represents an elapsed time, measured in seconds, since the epoch. Dynamic Semantics
  18. 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.
  19. 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 rounded to the nearest exactly representable value (away from zero if exactly halfway between two exactly representable values).
  20. To_Duration(Time_Span_Zero) returns 0.0, and To_Time_Span(0.0) returns Time_Span_Zero.
  21. The functions Nanoseconds, Microseconds, and Milliseconds convert the input 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 representable value (away from zero if exactly halfway between two exactly representable values).
  22. The effects of the operators on Time and Time_Span are as for the operators defined for integer types.
  23. The function Clock returns the amount of time since the epoch.
  24. 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
  25. 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.
  26. Time_Span_First shall be no greater than -3600 seconds, and Time_Span_Last shall be no less than 3600 seconds.
  27. 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
  28. The implementation shall document the values of Time_First, Time_Last, Time_Span_First, Time_Span_Last, Time_Span_Unit, and Tick.
  29. 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.
  30. 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.
  31. The implementation shall document any aspects of the the external environment that could interfere with the clock behavior as defined in this clause. Metrics
  32. For the purpose of the metrics defined in this clause, real time is defined to be the International Atomic Time (TAI).
  33. The implementation shall document the following metrics:
    1. 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   = Clock   then t2 - t1 <= D.
                  t1        t2
      
    2. An upper bound on the size of a clock jump.
    3. An upper bound on the drift rate of Clock with respect to real time. This is a real number D such that
    4. E*(1-D) <= (Clock    - Clock ) <= E*(1+D)
                       t+E        t
      
      provided that: Clock  + E*(1+D) <= Time_Last.
                          t
      
    5. where Clock  is the value of Clock at time t, and E is a real time
                 t
      time duration not less than 24 hours. The value of E used for this
      metric shall be reported. @end format
      
      
    6. An upper bound on the execution time of a call to the Clock function, in processor clock cycles.
    7. Upper bounds on the execution times of the operators of the types Time and Time_Span, in processor clock cycles.
Implementation Permissions
  1. 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
  2. When appropriate, implementations should provide configuration mechanisms to change the value of Tick.
  3. It is recommended that Calendar.Clock and Real_Time.Clock be implemented as transformations of the same time base.
  4. 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
  5. (30) The rules in this clause do not imply that the implementation can protect the user from operator or installation errors which could result in the clock being set incorrectly.
  6. (31) 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.

Delay Accuracy

  1. This clause 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:
    1. If C  is a value of Clock read before a task executes a
          1
      delay_relative_statement with duration D, and C  is a value of Clock
                                                     2
      read after the task resumes execution following that delay_statement,
      then C  - C  >= D.
            2    1
      
    2. 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.
  1. 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 section Protected Subprograms and Protected Actions.
  2. 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 selective_accept_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
  3. The implementation shall document the minimum value of the delay expression of a delay_relative_statement that causes the task to actually be blocked.
  4. 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
  5. The implementation shall document the following metrics:
    1. 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.
    2. 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.
    3. 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.
    4. 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.
    NOTES
  1. (32) The execution time of a delay_statement that does not cause the task to be blocked (e.g. "delay 0.0;" ) is of interest in situations where delays are used to achieve voluntary round-robin task dispatching among equal-priority tasks.

Synchronous Task Control

  1. This clause 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. package Ada.Synchronous_Task_Control is
    
  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. Dynamic Semantics
  6. An object of the type Suspension_Object has two visible states: true and false. Upon initialization, its value is set to false.
  7. 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. 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 section Protected Subprograms and Protected Actions. 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.

Asynchronous Task Control

  1. This clause 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. with Ada.Task_Identification;
    package Ada.Asynchronous_Task_Control is
      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. 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.
  5. 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 section Task Priorities, and the value of the held priority is defined to be such a source instead.
  6. The Continue operation resets the state of T to not-held; T's active priority is then reevaluated as described in D.1. This time, T's base priority is taken into account.
  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. (33) 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. (34) The effect of calling Get_Priority and Set_Priority on a Held task is the same as on any other task.
  13. (35) Calling Hold on a held task or Continue on a non-held task has no effect.
  14. (36) The rules affecting queuing are derived from the above rules, in addition to the normal priority rules:
    1. 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.
    2. 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.
    3. 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.
    4. If a task becomes held while waiting in a 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 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.
    5. 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.

Other Optimizations and Determinism Rules

  1. This clause describes various requirements for improving the response and determinism in a real-time system. Implementation Requirements
  2. If the implementation blocks interrupts, see section Interrupt Support, 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 section Protected Subprograms and Protected Actions, 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:
    1. The overhead associated with obtaining a mutual-exclusive access to an entry-less protected object. This shall be measured in the following way:
      1. For a protected object of the form:
      2. protected Lock is
           procedure Set;
           function Read return Boolean;
        private
           Flag : Boolean := False;
        end Lock;
        
      3. protected body Lock is
           procedure Set is
           begin
              Flag := True;
           end Set;
           function Read return Boolean
           Begin
              return Flag;
           end Read;
        end Lock;
        
      4. 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.
      5. 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.


Go to the first, previous, next, last section, table of contents.