CVS difference for ais/ai-00210.txt

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

--- ais/ai-00210.txt	1998/10/01 19:02:55	1.1
+++ ais/ai-00210.txt	1998/10/01 19:10:53	1.2
@@ -1,9 +1,9 @@
 !standard H.4      (24)                             98-10-01  AI95-00210/00
 !standard H.4      (27)
-!class ramification 98-10-01
+!class confirmation 98-10-01
 !status received 98-10-01
 !priority Medium
-!difficulty Medium
+!difficulty Easy
 !subject Questions on pragma Restriction No_Recursion and No_Reentrancy
 
 !summary 98-10-01
@@ -89,6 +89,247 @@
   DDC-I A/S                         Phone:   +45 45 87 20 77 ext. 320
   Gl. Lundtoftevej 1 B            Telefax:   +45 45 87 22 17
   DK-2800 Lyngby,  Denmark      Secretary:   +45 45 87 11 44
+
+*************************************************************
+
+From: 	Sven H. Sorensen[SMTP:shs@ddci.dk]
+Sent: 	Tuesday, April 28, 1998 3:47 AM
+Subject: 	Re: pragma Restriction(No_Recursion) and pragma Restriction(No_Reentrancy)
+
+
+!topic     Must pragma Restriction(No_Recursion) and pragma Restriction(No_Reentrancy) be checked for at compile-time, link-time or run-time?
+!reference RM95-13.12(8), RM95-H.4(27)
+!from      Sven Soerensen 98-04-28
+<<reference as: 1998-15860.a Sven H. Sorensen 1998-4-28>>
+!discussion
+ Ted Baker 98-04-27:
+ >| Neither pragma Restriction(No_Recursion) nor pragma
+ >| Restriction(No_Reentrancy) can (in general at least) be checked statically.
+ >| Must we make run-time tests in order to conform with Annex H?
+ >
+ >No.
+ >
+ >| RM 13.12(8):
+ >|      A pragma Restrictions is a configuration pragma;
+ >|      unless otherwise specified for a particular restriction, a partition
+ >|      ^^^^^^^^^^^^^^^^^^^^^^^^^^
+ >|      shall obey the restriction if a pragma Restrictions applies to any
+ >|      compilation unit included in the partition.
+ >
+ >The above "shall" is a requirement on applications, not on
+ >implementations.
+ >
+ >| RM H.4(27):
+ >|      Program execution is erroneous if pragma Restrictions(No_Recursion)
+ >|      has been specified and a subprogram is invoked as part of its own
+ >|      execution, or if pragma Restrictions(No_Reentrancy) has been specified
+ >|      and during the execution of a subprogram by a task, another task
+ >|      invokes the same subprogram.
+ >
+ >The above "erroneous" again puts the burden of compliance on the
+ >application.
+ >
+ >| Is RM H.4(27) allowing us not to check the two restrictions, i.e., let it
+ >| be up to the user to write code that conform with the restrictions?
+ >
+ >Right.
+ >
+ >| It seems to me that the two paragraphs are in direct contradiction with each
+ >| other.
+ >
+ >I don't see any contradiction.
+
+I am still confused. RM-13.12(8) is under the term
+"Post-Compilation Rules".
+
+RM-1.1.2(29):
+                Post-Compilation Rules
+
+        Rules that are enforced before running a partition. A
+        partition is legal if its compilation units are legal and
+        it obeys all of the Post-Compilation Rules.
+
+Restrictions must in other words be checked before running the
+program.  This is, as I see it, in contradiction with the
+RM-H.4(27).
+
+
+!topic     Does pragma Restriction(No_Recursion) and pragma Restriction(No_Reentrancy) apply to the RTS as well?
+!reference RM95-H.4(24)
+!from      Sven Soerensen 98-04-28
+<<reference as: 1998-15860.b Sven H. Sorensen 1998-4-28>>
+!discussion
+ Ted Baker 98-04-27:
+ >| AARM H.4(24):
+ >|      If an implementation supports pragma Restrictions for a particular
+ >|      argument, then except for the restrictions No_Unchecked_Deallocation,
+ >|      No_Unchecked_Conversion, No_Access_Subprograms, and
+ >|      No_Unchecked_Access, the associated restriction applies to the
+ >|      run-time system.
+ >
+ >| Making a RTS that is free of Recursion is of course possible. However,
+ >| a RTS that is not reentrant does not make much sense.  For instance, on
+ >| task can be suspended in an accept statement while another task calls an
+ >| accept statement.
+ >
+ >Admittedly, non-reentrancy does not make sense in a runtime system
+ >that supports multi-tasking.  Therefore, I would be forced to
+ >interpret the restriction as limiting the runtime system to a
+ >single task.
+ >
+ >--Ted Baker
+ >
+
+But there is a restriction limiting the run-time system to a
+single task, namely pragma Restriction(Max_Tasks => 0).  Are the
+two restrictions equivalent?
+
+Sven Soerensen
+
+-- 
+  Sven Henrik Soerensen             Email:   shs@ddci.dk
+  DDC-I A/S                         Phone:   +45 45 87 20 77 ext. 320
+  Gl. Lundtoftevej 1 B            Telefax:   +45 45 87 22 17
+  DK-2800 Lyngby,  Denmark      Secretary:   +45 45 87 11 44
+
+*************************************************************
+
+From: 	Ted Baker[SMTP:baker@dad.cs.fsu.edu]
+Sent: 	Monday, May 04, 1998 6:53 AM
+Subject: 	Re: pragma Restriction(No_Recursion) and pragma Restriction(No_Reentrancy)
+
+!topic     Must pragma Restriction(No_Recursion) and pragma Restriction(No_Reentrancy) be checked for at compile-time, link-time or run-time?
+!reference RM95-13.12(8), RM95-H.4(27)
+<<reference as: 1998-15862.a Ted Baker  1998-5-4>>
+!discussion
+
+| No one answered this, so I thought I would ask you directly.
+
+The ARG has a big backlog of comments, so it could be a long time
+before you see any formal action.  I was hoping somebody else
+would comment, though, as I had already tried my best to answer,
+but I'm just one member of the ARG.  I'll say some more, but it
+may be that eventually some other ARG members will comment, and
+possibly disagree.
+
+--Ted Baker
+
+|>| Neither pragma Restriction(No_Recursion) nor pragma
+|>| Restriction(No_Reentrancy) can (in general at least) be checked statically.
+|>| Must we make run-time tests in order to conform with Annex H?
+|>
+|>No.
+|>
+|>| RM 13.12(8):
+|>|      A pragma Restrictions is a configuration pragma;
+|>|      unless otherwise specified for a particular restriction, a partition
+|>|      ^^^^^^^^^^^^^^^^^^^^^^^^^^
+|>|      shall obey the restriction if a pragma Restrictions applies to any
+|>|      compilation unit included in the partition.
+|>
+|>The above "shall" is a requirement on applications, not on
+|>implementations.
+|>
+|>| RM H.4(27):
+|>|      Program execution is erroneous if pragma Restrictions(No_Recursion)
+|>|      has been specified and a subprogram is invoked as part of its own
+|>|      execution, or if pragma Restrictions(No_Reentrancy) has been specified
+|>|      and during the execution of a subprogram by a task, another task
+|>|      invokes the same subprogram.
+|>
+|>The above "erroneous" again puts the burden of compliance on the
+|>application.
+|>
+|>| Is RM H.4(27) allowing us not to check the two restrictions, i.e., let it
+|>| be up to the user to write code that conform with the restrictions?
+|>
+|>Right.
+|>
+|>| It seems to me that the two paragraphs are in direct contradiction with each
+|>| other.
+|>
+|>I don't see any contradiction.
+
+| I am still confused. RM-13.12(8) is under the term
+| "Post-Compilation Rules".
+| RM-1.1.2(29):
+|                 Post-Compilation Rules
+|         Rules that are enforced before running a partition. A
+|         partition is legal if its compilation units are legal and
+|         it obeys all of the Post-Compilation Rules.
+| Restrictions must in other words be checked before running the
+| program.  This is, as I see it, in contradiction with the
+| RM-H.4(27).
+
+13.12 (8) is a general statement about configuration pragmas.
+Note where I underlined "unless otherwise specified".
+If you read H.4(27), you will see that it specifies otherwise,
+by saying that the "program execution is erroneous" for No_Recursion
+and No_Reentrancy.  Implementations are not required to do checks
+for erroneous execution.
+
+|>| AARM H.4(24):
+|>|      If an implementation supports pragma Restrictions for a particular
+|>|      argument, then except for the restrictions No_Unchecked_Deallocation,
+|>|      No_Unchecked_Conversion, No_Access_Subprograms, and
+|>|      No_Unchecked_Access, the associated restriction applies to the
+|>|      run-time system.
+|>
+|>| Making a RTS that is free of Recursion is of course possible. However,
+|>| a RTS that is not reentrant does not make much sense.  For instance, on
+|>| task can be suspended in an accept statement while another task calls an
+|>| accept statement.
+|>
+|>Admittedly, non-reentrancy does not make sense in a runtime system
+|>that supports multi-tasking.  Therefore, I would be forced to
+|>interpret the restriction as limiting the runtime system to a
+|>single task.
+
+| But there is a restriction limiting the run-time system to a
+| single task, namely pragma Restriction(Max_Tasks => 0).  Are the
+| two restrictions equivalent?
+
+To be honest, Annexes D and H were written more or less independently,
+by diffferent people, with little concern about possible overlap.
+
+The intentions were somewhat different.  Annex D was more
+concerned about restrictions to improve performance, whereas Annex
+D was more concerned about restrictions to make the implementation
+simpler and easier to analyze.  As an author of Annex D, I can
+vouche that Max_Tasks was mainly intended to allow use of a
+runtime system that supports tasking, but with static allocation
+of per-task data (task control blocks).  In contrast, I guess the
+intent in Annex H was to completely eliminate multi-tasking
+support from the runtime system, and synchronization calls from
+all other libraries.
+
+*************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Thursday, May 07, 1998 8:58 AM
+Subject: 	Re: pragma Restriction(No_Recursion) and pragma Restriction(No_Reentrancy)
+
+!topic     Must pragma Restriction(No_Recursion) and pragma Restriction(No_Reentrancy) be checked for at compile-time, link-time or run-time?
+!reference RM95-13.12(8), RM95-H.4(27)
+!reference 1998-15862.a Ted Baker  1998-5-4
+!from Bob Duff
+<<reference as: 1998-15864.a Robert A Duff 1998-5-7>>
+!discussion
+
+>...  I was hoping somebody else
+> would comment, though, as I had already tried my best to answer,
+> but I'm just one member of the ARG.  I'll say some more, but it
+> may be that eventually some other ARG members will comment, and
+> possibly disagree.
+
+I agree with everything Ted says here.
+The key point is:
+
+> Note where I underlined "unless otherwise specified".
+> If you read H.4(27), you will see that it specifies otherwise,
+...
+
+- Bob
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent