D.7 Tasking Restrictions

[This clause defines restrictions that can be used with a pragma Restrictions (see 13.12) to facilitate the construction of highly efficient tasking run-time systems.]

Static Semantics

The following restriction_identifiers are language defined:

{Restrictions (No_Task_Hierarchy)} No_Task_Hierarchy: All (nonenvironment) tasks depend directly on the environment task of the partition.

4/1

{8652/0042} {Restrictions (No_Nested_Finalization)} No_Nested_Finalization: Objects with controlled, protected, or task parts and access types that designate such objects, shall be declared only at library level.

4.a/1

This paragraph was deleted.Ramification: {8652/0042} ~~Note that protected types with entries and interrupt-handling protected types have nontrivial finalization actions. However, this restriction does not restrict those things.~~

{Restrictions (No_Abort_Statements)} No_Abort_Statements: There are no abort_statements, and there are no calls on Task_Identification.Abort_Task.

{Restrictions (No_Terminate_Alternatives)} No_Terminate_Alternatives: There are no selective_accepts with terminate_alternatives.

{Restrictions (No_Task_Allocators)} No_Task_Allocators: There are no allocators for task types or types containing task subcomponents.

{Restrictions (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 require heap storage allocation are implementation defined.

8.a

Implementation defined: Any operations that implicitly require heap storage allocation.

No_Dynamic_Priorities: There are no semantic dependences on the package Dynamic_Priorities. {Restrictions (No_Dynamic_Priorities)}

{Restrictions (No_Asynchronous_Control)} No_Asynchronous_Control: There are no semantic dependences on the package Asynchronous_Task_Control.

The following restriction_parameter_identifiers are language defined:

{Restrictions (Max_Select_Alternatives)} Max_Select_Alternatives: Specifies the maximum number of alternatives in a selective_accept.

{Restrictions (Max_Task_Entries)} 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.]

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. {Restrictions (Max_Protected_Entries)}

Dynamic Semantics

15/1

This paragraph was deleted.{8652/0076} If the following restrictions are violated, the behavior is implementation defined. {Storage_Check [partial]} {check, language-defined (Storage_Check)} {Storage_Error (raised by failure of run-time check)} If an implementation chooses to detect such a violation, Storage_Error should be raised.

The following restriction_parameter_identifiers are language defined:

17/1

{8652/0076} {Restrictions (Max_Storage_At_Blocking)} Max_Storage_At_Blocking: Specifies the maximum portion [(in storage elements)] of a task's Storage_Size that can be retained by a blocked task. If an implementation chooses to detect a violation of this restriction, Storage_Error should be raised; {Storage_Check [partial]} {check, language-defined (Storage_Check)} {Storage_Error (raised by failure of run-time check)} otherwise, the behavior is implementation defined .

18/1

{8652/0076} {Restrictions (Max_Asynchronous_Select_Nesting)} Max_Asynchronous_Select_Nesting: Specifies the maximum dynamic nesting level of asynchronous_selects. A value of zero prevents the use of any asynchronous_select and, if a program contains an asynchronous_select, it is illegal. If an implementation chooses to detect a violation of this restriction for values other than zero, Storage_Error should be raised; {Storage_Check [partial]} {check, language-defined (Storage_Check)} {Storage_Error (raised by failure of run-time check)} otherwise, the behavior is implementation defined .

19/1

{8652/0076} {Restrictions (Max_Tasks)} Max_Tasks: Specifies the maximum number of task creations that may be executed over the lifetime of a partition, not counting the creation of the environment task. A value of zero prevents any task creation and, if a program contains a task creation, it is illegal. If an implementation chooses to detect a violation of this restriction, Storage_Error should be raised; {Storage_Check [partial]} {check, language-defined (Storage_Check)} {Storage_Error (raised by failure of run-time check)} otherwise, the behavior is implementation defined .

19.a

Ramification: Note that this is not a limit on the number of tasks active at a given time; it is a limit on the total number of task creations that occur.

19.b

Implementation Note: We envision an implementation approach that places TCBs or pointers to them in a fixed-size table, and never reuses table elements.

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.

20.a

Implementation defined: Implementation-defined aspects of pragma Restrictions.

Implementation Advice

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

NOTES

29 The above Storage_Checks can be suppressed with pragma Suppress.

Contents Index Search Previous Next Legal