!standard D.7 (15) 00-04-11 AI95-00067/05 !standard D.7 (17-19) !class binding interpretation 95-07-27 !status Corrigendum 2000 99-07-28 !status WG9 Approved 97-11-14 !status ARG approved (7-0-3) subject to editorial review 97-04-11 !status work item 95-08-19 !status received 95-07-27 !priority Medium !difficulty Medium !qualifier Error !subject Pragma Restrictions(Max_Tasks, Max_Asynchronous_Select_Nesting) !summary For a pragma Restrictions(Max_Tasks => 0), task creation is illegal, for both the Real-Time Systems annex and the Safety and Security annex. Similarly, for a pragma Restrictions(Max_Asynchronous_Select_Nesting => 0), asynchronous_selects are illegal, for both of these annexes. !question The Real-Time Systems annex says in D.7(15) (of the Max_Tasks and Max_Asynchronous_Select_Nesting restrictions): 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. The Safety and Security annex says in H.4(2): The following restrictions, the same as in D.7, apply in this Annex: No_Task_Hierarchy, No_Abort_Statement, No_Implicit_Heap_Allocation, Max_Task_Entries is 0, Max_Asynchronous_Select_Nesting is 0, and Max_Tasks is 0. The last three restrictions are checked prior to program execution. Suppose an implementation complies with both annexes. Is the following example legal? (No.) pragma Restrictions (Max_Tasks => 0); procedure main is begin if false then declare task x is -- Legal? (No.) ... end if; end main; What does it mean that the restriction is "checked prior to program execution"? !recommendation An implementation conforming to the Safety and Security annex must support a pragma Restrictions(Max_Tasks => E), where E is a static expression whose value is zero. If such a pragma applies to a given compilation unit, then for an implementation conforming to the Real-Time Systems or Safety and Security annex (or both), the compilation unit is illegal if it contains an object_declaration or allocator, where the type of the created object is a task type, or is a composite type with some subcomponent type that is a task type. An implementation conforming to the Safety and Security annex must support a pragma Restrictions(Max_Asynchronous_Select_Nesting => E), where E is a static expression whose value is zero. If such a pragma applies to a given compilation unit, then for an implementation conforming to the Real-Time Systems or Safety and Security annex (or both), the compilation unit is illegal if it contains an asynchronous_select. !wording (See corrigendum.) !discussion The intent is that it should be possible for a single implementation to comply with all of the Specialized Needs Annexes. Therefore, there cannot be contradictory requirements in two different Specialized Needs Annexes. "Max_Tasks is 0" should be interpreted to mean that a static expression is given, and its value is zero. Clearly, we cannot require compile-time detection unless the expression is static. But we don't want to interpret "is 0" to mean that it must be a literal with value zero, or a literal containing exactly the character "0" -- such a restriction would be inconsistent with other rules that need compile-time-known values. Thus, an expression like "00" or "1 - 1" should be allowed. What does it mean that the restriction is "checked prior to program execution"? This could be interpreted to mean a legality check, or could be interpreted to mean that a diagnostic message, such as a warning message, must be given at compile time, but the program is still legal, and may be executed. What exactly is being checked at compile time? The only reasonable interpretation would seem to be to check for the existence of an object_declaration or allocator, where the type of the created object is a task type, or is a composite type with some subcomponent type that is a task type. Thus, for example, a null array of tasks would fail this check. The following possible interpretations exist: 1. If the implementation supports the Real-Time annex, the example program is legal. If the implementation supports the Safety and Security annex, the example is illegal. We reject this interpretation, because it constitutes a contradiction between the two annexes. 2. If the expression is statically zero, then the example is illegal, if either annex is supported. This is the interpretation chosen. 3. If the expression is statically zero, then the example is legal. However, if the implementation conforms to the Safety and Security annex, then it must issue a warning message. There is some precedent for requiring warning messages -- see 2.8(13). This seems like a reasonable interpretation. However, it seems better to simply declare the program illegal -- a warning message doesn't have any particular value here. 4. Delete the requirement to check the restriction before run time. We reject this, because it does not satisfy the needs of the Safety and Security annex -- namely, to know at compile time whether the program is wrong. Similar arguments apply to Max_Asynchronous_Select_Nesting. !corrigendum D.07(15) @ddel 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. !corrigendum D.07(17) @drepl @xhang<@xterm Specifies the maximum portion (in storage elements) of a task's Storage_Size that can be retained by a blocked task.> @dby @xhang<@xterm 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; otherwise, the behavior is implementation defined.> !corrigendum D.07(18) @drepl @xhang<@xterm Specifies the maximum dynamic nesting level of @fas. A value of zero prevents the use of any @fa.> @dby @xhang<@xterm Specifies the maximum dynamic nesting of @fas. A value of zero prevents the use of any @fa and, if a program contains an @fa, it is illegal. If an implementation chooses to detect a violation of this restriction for values other than zero, Storage_Error should be raised; otherwise, the behavior is implementation defined.> !corrigendum D.07(19) @drepl @xhang<@xterm 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.> @dby @xhang<@xterm 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 for values other than zero, Storage_Error should be raised; otherwise, the behavior is implementation defined.> !ACATS test B-Tests for Annex D and H should be constructed to check that for Max_Tasks => 0 and Max_Asynchronous_Select_Nesting => 0, check that units violating the restrictions are rejected. !appendix !section D.7(00) !subject Pragma Restrictions in RT and Safety and Security annexes !reference RM95-D.7(00) !reference RM95-H.4(00) !from Bob Duff !reference as: 95-5214.b Robert A Duff 95-7-8>> !discussion I'm submitting this on behalf of Robert Dewar. In RT, Max_Tasks is a dynamic condition, which if checked, raises SE at runtime. In SS, Max_Tasks is a static condition that must be checked at compile time. pragma Restrictions (Max_Tasks => 0); procedure main is begin if false then declare task x is ... begin .. end; end if; end main; legal or not? clearly legal by D.7, but H.4 requires "checking prior to program execution" [whatever that means]. **************************************************************** !section D.7(00) !subject Pragma Restrictions in RT and Safety and Security annexes !reference RM95-D.7(00) !reference RM95-H.4(00) !reference as: 95-5214.b Robert A Duff 95-7-8 !from Offer pazy 95-7-29 !reference as: 95-5249.a Offer Pazy 95-7-29>> !discussion > > I'm submitting this on behalf of Robert Dewar. > > In RT, Max_Tasks is a dynamic condition, which if checked, raises SE > at runtime. In SS, Max_Tasks is a static condition that must be checked > at compile time. > > pragma Restrictions (Max_Tasks => 0); > procedure main is > begin > if false then > declare task x is ... begin .. end; > end if; > end main; > > legal or not? clearly legal by D.7, but H.4 requires "checking prior to > program execution" [whatever that means]. > [Some of this is the result of an off-line discussion with Bob and Tucker] The annexes should noyt conflict each other (that was the design requirement), so the above problem is presumably a bug. One possible solution (which I don't like) is to distinguish between Max_Task=0 and Max_Tasks>0. The former will be checked prior to program execution, and the latter may be checked at run-time. This wil aplly to both annexes. I would not recommend the introduction of such distinction (there are other similar restrictions). We can also say that the RT requires run-time check and the Safety and Security annex requires *in addition* a pre-run-time check. In general, the Max_Task in the two annexes have quite a different purpose: In the SS, it largely intended to mean Tasking:yes/no, in the Real-Time annex it is *intended* to have a value that will help pre-allocation of TCBs and sizing the task-id value (e.g. only 8-bits for 256 tasks). Maybe it wasn't a good idea to use the same parameter name. In the context of the Real-Time annex, there was a lot of debate (and controversy) with respect to the place of these checks, and I would hate to disturb the consensus that was achieved. Offer Pazy 31 Robinwood Ave. Boston, MA. 02130 USA (617)522-5988 pazy@world.std.com **************************************************************** !section D.7(00) !subject Pragma Restrictions in RT and Safety and Security annexes !reference RM95-D.7(00) !reference RM95-H.4(00) !reference 95-5214.b Robert A Duff 95-7-8 !reference 95-5249.a Offer Pazy 95-7-29 !from Robert I. Eachus 95-8-1 !reference as: 95-5250.a Robert I. Eachus 95-8-1>> !discussion pazy@world.std.com (Offer Pazy) said (among other things): > We can also say that the RT requires run-time check and the Safety and Security annex > requires *in addition* a pre-run-time check. I think that this is the only reasonable interpretation. First, not that the wording in H.4 says clearly that the compile time check only required for Max_Tasks = 0. I believe that a reasonable implementation for annex D is to replace all task declarations with code to raise Program_Error, and that annex H requires instead that Max_Tasks specifically equal to zero cause a compile or link time error. I also feel that this should be interpreted as a permission for any implementation to reject a compilation unit at compile time if it contains a task and a pragma Restrictions(Max_Tasks = 0) applies. (It should always be legitimate to partially support any annex.) Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... **************************************************************** !from Mike Kamrad 99-07-06 In the course of completing this wording assignment, I came across several issues which I think needed to be addressed:I Does the same wording apply to D.7(13)?? Is the last sentence of H.4(2) no longer needed?? Does the permission of the last sentence of 13.12(9) get changed from "are" to "may be"?? ****************************************************************