CVS difference for ais/ai-00067.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00067.txt

--- ais/ai-00067.txt	1998/09/30 00:17:12	1.1
+++ ais/ai-00067.txt	1999/07/29 00:51:01	1.2
@@ -1,5 +1,6 @@
-!standard D.7      (00)                               97-11-14  AI95-00067/02
+!standard D.7      (00)                               99-07-28  AI95-00067/03
 !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
@@ -8,14 +9,14 @@
 !difficulty Medium
 !subject Pragma Restrictions(Max_Tasks, Max_Asynchronous_Select_Nesting)
 
-!summary 97-05-08
+!summary
 
 For a pragma Restrictions(Max_Tasks => 0), task creation is illegal, for
 both the Real Time 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 95-07-27
+!question
 
 The Real Time Systems annex says in D.7 (of the Max_Tasks and
 Max_Asynchronous_Select_Nesting restrictions):
@@ -37,7 +38,7 @@
     pragma Restrictions (Max_Tasks => 0);
     procedure main is
     begin
-       if false then 
+       if false then
           declare
              task x is -- Legal?  (No.)
              ...
@@ -47,7 +48,7 @@
 What does it mean that the restriction is "checked prior to program
 execution"?
 
-!recommendation 97-05-08
+!recommendation
 
 An implementation conforming to the SS annex must support a pragma
 Restrictions(Max_Tasks => E), where E is a static expression whose value
@@ -64,10 +65,12 @@
 annex (or both), the compilation unit is illegal if it contains an
 asynchronous_select.
 
-!wording 97-05-08
+!wording
 
-!discussion 95-07-27
+(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 SN Annexes.
@@ -118,9 +121,64 @@
        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)
 
-!appendix 95-08-19
+@drepl
+@xhang<Max_Storage_At_Blocking@hr@tab
+Specifies the maximum portion (in storage elements) of a
+task's Storage_Size that can be retained by a blocked task.>
+@dby
+@xhang<Max_Storage_At_Blocking@hr@tab
+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
+such a violation, Storage_Error should be raised; otherwise, the behavior is
+implementation-defined.>
+
+!corrigendum D.07(18)
+
+@drepl
+@xhang<Max_Asynchronous_Select_Nesting@hr@tab
+Specifies the maximum dynamic nesting level of @fa<asynchronous_select>s.
+A value of zero prevents the use of any @fa<asynchronous_select>.>
+@dby
+@xhang<Max_Asynchronous_Select_Nesting@hr@tab
+Specifies the maximum dynamic nesting of @fa<asynchronous_select>s. A value of
+zero prevents the use of any @fa<asynchronous_select> and, if a program
+contains an @fa<asynchronous_select>, it is illegal. If an implementation
+chooses to detect such a violation for values other than zero, Storage_Error
+should be raised; otherwise, the behavior is implementation-defined.>
+
+!corrigendum D.07(19)
+
+@drepl
+@xhang<Max_Tasks@hr@tab
+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<Max_Tasks@hr@tab
+Specifies the maximum number of task creations that be executed over the
+lifetime of a partition, not counting the creation of the environment task. A
+value of zero prevents the any task creation and, if a program contains a task
+creation, it is illegal.  If an implementation chooses to detect such a
+violation 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 SS annexes
 !reference RM95-D.7(00)
@@ -138,12 +196,12 @@
     pragma Restrictions (Max_Tasks => 0);
     procedure main is
     begin
-       if false then 
+       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 
+legal or not? clearly legal by D.7, but H.4 requires "checking prior to
 program execution" [whatever that means].
 
 ****************************************************************
@@ -158,47 +216,47 @@
 
 !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 
+>        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 
+>
+> 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 
+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 
+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 SS annex 
+We can also say that the RT requires run-time check and the SS 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 RT 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 
+In the SS, it largely intended to mean Tasking:yes/no, in the RT 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 RT annex, there was a lot of debate (and controversy) 
-with respect to the place of these checks, and I would hate to disturb the 
+In the context of the RT 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.
 
 
@@ -224,7 +282,7 @@
 
    pazy@world.std.com (Offer Pazy) said (among other things):
 
-> We can also say that the RT requires run-time check and the SS annex 
+> We can also say that the RT requires run-time check and the SS annex
 > requires *in addition* a pre-run-time check.
 
    I think that this is the only reasonable interpretation.  First,
@@ -246,5 +304,20 @@
 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"??
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent