3.11. Annex D: Real-Time Systems

Q: D.3(17): Locking Policies
Q: D.4(16): Entry Queuing Policies
Q: D.6(9-10): Preemptive Abort
Q: (continued)
Q: D.7(21): Tasking Restrictions
Q: D.8(47-49): Monotonic Time
Q: (continued)
Q: (continued)

Q: D.3(17): Locking Policies

The implementation should use names that end with _Locking for locking policies defined by the implementation.

A: Followed. No such implementation-defined locking policies exist.

Q: D.4(16): Entry Queuing Policies

Names that end with _Queuing should be used for all implementation-defined queuing policies.

A: Followed. No such implementation-defined queuing policies exist.

Q: D.6(9-10): Preemptive Abort

Even though the abort_statement is included in the list of potentially blocking operations (see 9.5.1), it is recommended that this statement be implemented in a way that never requires the task executing the abort_statement to block.

A: Not applicable.

Q: (continued)

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.

A: Not applicable.

Q: D.7(21): Tasking Restrictions

When feasible, the implementation should take advantage of the specified restrictions to produce a more efficient implementation.

A: Followed.

Q: D.8(47-49): Monotonic Time

When appropriate, implementations should provide configuration mechanisms to change the value of Tick.

A: Not Followed.

Q: (continued)

It is recommended that Calendar.Clock and Real_Time.Clock be implemented as transformations of the same time base.

A: Not Followed. Package Calendar is prohibited by the built-in restriction No_Calendar.

Q: (continued)

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.

A: Followed.