!standard H.4 (24) 99-07-28 AI95-00210/03 !standard H.4 (27) !class confirmation 98-10-01 !status WG9 approved 99-06-12 !status ARG Approved (with changes) 8-1-1 99-03-25 !status work item 99-03-23 !status received 98-10-01 !priority Medium !difficulty Easy !subject Questions on pragma Restriction No_Recursion and No_Reentrancy !summary The No_Recursion and No_Reentrancy restrictions need not be checked statically, nor at run-time. A program execution is erroneous if it violates either of these restrictions when they have been specified for the partition. Both of these restrictions apply to the run-time system if specified for a partition. !question 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.) Do pragma Restriction(No_Recursion) and pragma Restriction(No_Reentrancy) apply to the runtime system? (Yes.) !response Although restrictions must generally be enforced prior to execution, per 13.12(8), this requirement can be relaxed for particular restrictions. In the case of No_Recursion and No_Reentrancy, violating these restrictions is specified as erroneous (see H.4(27)). Hence, these restrictions need not be enforced prior to execution, nor at run-time. H.4(24) indicates that No_Recursion and No_Reentrancy apply to the run-time system as well as to the user's program units. !ACATS test The ruling is not testable; it confirms erroneous cases, which are untestable. !appendix !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, DDC-I A/S, Denmark, shs@ddci.dk !discussion 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? 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. 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. 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? It seems to me that the two paragraphs are in direct contradiction with each other. ------- !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, DDC-I A/S, Denmark, shs@ddci.dk !discussion 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. Regards, Sven -- 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: 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 <> !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 <> !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) <> !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 <> !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 *************************************************************