Version 1.6 of ais/ai-00210.txt

!topic     Must pragma Restriction(No_Recursion) and pragma
<<reference as: 1998-15856.a Sven H. Sorensen 1998-4-24>>
           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
<<reference as: 1998-15856.b Sven H. Sorensen 1998-4-24>>
           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
<<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

*************************************************************