Version 1.7 of ais/ai-00067.txt

Unformatted version of ais/ai-00067.txt version 1.7
Other versions for file ais/ai-00067.txt

!standard D.7 (15)          00-04-11 AI95-00067/05
!standard D.7 (17-19)
!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
!status received 95-07-27
!priority Medium
!difficulty Medium
!qualifier Error
!subject Pragma Restrictions(Max_Tasks, Max_Asynchronous_Select_Nesting)
!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
The Real Time Systems annex says in D.7(15) (of the Max_Tasks and Max_Asynchronous_Select_Nesting restrictions):
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.
The Safety and Security annex says in H.4(2):
The following restrictions, the same as in D.7, apply in this Annex: No_Task_Hierarchy, No_Abort_Statement, No_Implicit_Heap_Allocation, Max_Task_Entries is 0, Max_Asynchronous_Select_Nesting is 0, and Max_Tasks is 0. The last three restrictions are checked prior to program execution.
Suppose an implementation complies with both annexes. Is the following example legal? (No.)
pragma Restrictions (Max_Tasks => 0); procedure main is begin
if false then declare task x is -- Legal? (No.) ... end if;
end main;
What does it mean that the restriction is "checked prior to program execution"?
!recommendation
An implementation conforming to the Safety and Security annex must support a pragma Restrictions(Max_Tasks => E), where E is a static expression whose value is zero. If such a pragma applies to a given compilation unit, then for an implementation conforming to the Real-Time or Safety and Security annex (or both), the compilation unit is illegal if it contains an object_declaration or allocator, where the type of the created object is a task type, or is a composite type with some subcomponent type that is a task type.
An implementation conforming to the Safety and Security annex must support a pragma Restrictions(Max_Asynchronous_Select_Nesting => E), where E is a static expression whose value is zero. If such a pragma applies to a given compilation unit, then for an implementation conforming to the Real-Time or Safety and Security annex (or both), the compilation unit is illegal if it contains an asynchronous_select.
!wording
(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 Specialized Needs Annexes.
"Max_Tasks is 0" should be interpreted to mean that a static expression is given, and its value is zero. Clearly, we cannot require compile-time detection unless the expression is static. But we don't want to interpret "is 0" to mean that it must be a literal with value zero, or a literal containing exactly the character "0" -- such a restriction would be inconsistent with other rules that need compile-time-known values. Thus, an expression like "00" or "1 - 1" should be allowed.
What does it mean that the restriction is "checked prior to program execution"? This could be interpreted to mean a legality check, or could be interpreted to mean that a diagnostic message, such as a warning message, must be given at compile time, but the program is still legal, and may be executed.
What exactly is being checked at compile time? The only reasonable interpretation would seem to be to check for the existence of an object_declaration or allocator, where the type of the created object is a task type, or is a composite type with some subcomponent type that is a task type. Thus, for example, a null array of tasks would fail this check.
The following possible interpretations exist:
1. If the implementation supports the Real-Time annex, the example program
is legal. If the implementation supports the Safety and Security annex, the example is illegal. We reject this interpretation, because it constitutes a contradiction between the two annexes.
2. If the expression is statically zero, then the example is illegal,
if either annex is supported. This is the interpretation chosen.
3. If the expression is statically zero, then the example is legal.
However, if the implementation conforms to the Safety and Security annex, then it must issue a warning message. There is some precedent for requiring warning messages -- see 2.8(13). This seems like a reasonable interpretation. However, it seems better to simply declare the program illegal -- a warning message doesn't have any particular value here.
4. Delete the requirement to check the restriction before run time.
We reject this, because it does not satisfy the needs of the SS annex -- namely, to know at compile time whether the program is wrong.
Similar arguments apply to Max_Asynchronous_Select_Nesting.
!corrigendum D.07(15)
Delete the paragraph:
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)
Replace the paragraph:
Max_Storage_At_Blocking
Specifies the maximum portion (in storage elements) of a task's Storage_Size that can be retained by a blocked task.
by:
Max_Storage_At_Blocking
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 a violation of this restriction, Storage_Error should be raised; otherwise, the behavior is implementation defined.
!corrigendum D.07(18)
Replace the paragraph:
Max_Asynchronous_Select_Nesting
Specifies the maximum dynamic nesting level of asynchronous_selects. A value of zero prevents the use of any asynchronous_select.
by:
Max_Asynchronous_Select_Nesting
Specifies the maximum dynamic nesting of asynchronous_selects. A value of zero prevents the use of any asynchronous_select and, if a program contains an asynchronous_select, it is illegal. If an implementation chooses to detect a violation of this restriction for values other than zero, Storage_Error should be raised; otherwise, the behavior is implementation defined.
!corrigendum D.07(19)
Replace the paragraph:
Max_Tasks
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.
by:
Max_Tasks
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. A value of zero prevents any task creation and, if a program contains a task creation, it is illegal. If an implementation chooses to detect a violation of this restriction 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 Safety and Security annexes
!reference RM95-D.7(00)
!reference RM95-H.4(00)
!from Bob Duff
!reference as: 95-5214.b Robert A Duff 95-7-8>>
!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
          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
program execution" [whatever that means].

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

!section D.7(00)
!subject Pragma Restrictions in RT and Safety and Security annexes
!reference RM95-D.7(00)
!reference RM95-H.4(00)
!reference as: 95-5214.b Robert A Duff 95-7-8
!from Offer pazy 95-7-29
!reference as: 95-5249.a Offer Pazy 95-7-29>>

!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
>           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
> 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
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
are other similar restrictions).

We can also say that the RT requires run-time check and the Safety and Security 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 Real-Time 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 Real-Time 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.


Offer Pazy
31 Robinwood Ave.
Boston, MA. 02130
USA
(617)522-5988
pazy@world.std.com

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

!section D.7(00)
!subject Pragma Restrictions in RT and Safety and Security annexes
!reference RM95-D.7(00)
!reference RM95-H.4(00)
!reference 95-5214.b Robert A Duff 95-7-8
!reference 95-5249.a Offer Pazy 95-7-29
!from Robert I. Eachus 95-8-1
!reference as: 95-5250.a Robert I. Eachus 95-8-1>>

!discussion

   pazy@world.std.com (Offer Pazy) said (among other things):

> We can also say that the RT requires run-time check and the Safety and Security annex
> requires *in addition* a pre-run-time check.

   I think that this is the only reasonable interpretation.  First,
not that the wording in H.4 says clearly that the compile time check
only required for Max_Tasks = 0.  I believe that a reasonable
implementation for annex D is to replace all task declarations with
code to raise Program_Error, and that annex H requires instead that
Max_Tasks specifically equal to zero cause a compile or link time
error.

   I also feel that this should be interpreted as a permission for any
implementation to reject a compilation unit at compile time if it
contains a task and a pragma Restrictions(Max_Tasks = 0) applies.  (It
should always be legitimate to partially support any annex.)


                                        Robert I. Eachus

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