Contents   Index   Previous   Next

D.7 Tasking Restrictions

1
   [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

2
   The following restriction_identifiers are language defined:
3
   {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.
5
   {Restrictions (No_Abort_Statements)} No_Abort_Statements
There are no abort_statements, and there are no calls on Task_Identification.Abort_Task.
6
   {Restrictions (No_Terminate_Alternatives)} No_Terminate_Alternatives
There are no selective_accepts with terminate_alternatives.
7
   {Restrictions (No_Task_Allocators)} No_Task_Allocators
There are no allocators for task types or types containing task subcomponents.
8
   {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.
9
   No_Dynamic_Priorities
There are no semantic dependences on the package Dynamic_Priorities. {Restrictions (No_Dynamic_Priorities)}
10
    {Restrictions (No_Asynchronous_Control)} No_Asynchronous_Control
There are no semantic dependences on the package Asynchronous_Task_Control.
11
    The following restriction_parameter_identifiers are language defined:
12
    {Restrictions (Max_Select_Alternatives)} Max_Select_Alternatives
Specifies the maximum number of alternatives in a selective_accept.
13
    {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.]
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. {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.
16
    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.
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.
20.a
Implementation defined: Implementation-defined aspects of pragma Restrictions.

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.

Contents   Index   Previous   Next   Legal