!standard H.4 (24) 98-10-01 AI95-00210/00 !standard H.4 (27) !class confirmation 98-10-01 !status received 98-10-01 !priority Medium !difficulty Easy !subject Questions on pragma Restriction No_Recursion and No_Reentrancy !summary 98-10-01 !question 98-10-01 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? Does pragma Restriction(No_Recursion) and pragma Restriction(No_Reentrancy) apply to the runtime 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. !response 98-10-01 !appendix 98-10-01 !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 *************************************************************