Version 1.1 of ai12s/ai12-0344-1.txt

Unformatted version of ai12s/ai12-0344-1.txt version 1.1
Other versions for file ai12s/ai12-0344-1.txt

!standard 5.5.3(16/5)          19-09-30 AI12-0344-1/01
!standard 5.5.3(20/5)
!standard 5.5.3(22/5)
!class Amendment 19-09-30
!status work item 19-09-30
!status received 19-08-19
!priority Low
!difficulty Easy
!subject
!summary
Allows_Exit and Parallel_Iterator can only be applied to subprograms with a single access-to-procedure parameter.
Aspect Parallel_Calls is defined to check that a procedure can be called in parallel.
!problem
The legality requirement for Allows_Exit and Parallel_Iterator aspects says that the callable entity shall have at least one parameter of an anonymous access-to-subprogram type. If there are multiple such parameters, how do we know which parameter is the "loop body procedure" which is mentioned in the description of the semantics of the aspects?
If the user explicitly passes a procedure to a subprogram with Parallel_Iterator => True, there is no checking on that subprogram (unlike what happens when the subprogram is used in a procedural iterator loop).
!proposal
(See Summary.)
!wording
Modify 5.5.3(16/5):
The following aspects may be specified for a callable entity S that has at {exactly}[least] one formal parameter of an anonymous access-to-{procedure}[subprogram] type:
[Editor's note: A loop body procedure can't be a function, so why allow a parameter that is an access-to-function?]
Add after 5.5.3(20/5):
The following aspect can be specified for a procedure P:
Parallel_Calls
The Parallel_Calls aspect is of type Boolean. The specified value shall be static. The Parallel_Calls aspect of an inherited primitive procedure is True if Parallel_Calls is True either for the corresponding procedure of the progenitor type or for any other inherited procedure that it overrides. If not specified or inherited as True, the Parallel_Calls aspect of a procedure is False.
Specifying the Parallel_Calls aspect to be True for a procedure indicates that the procedure may be safely called in parallel. Conflict checks (if required by the Conflict_Check_Policy in effect (see 9.10.1)) are made on the procedure assuming that multiple concurrent calls exist.
The Parallel_Calls aspect of a loop body procedure is True if the reserved word parallel occurs in the corresponding loop statement, and False otherwise.
Add after 5.5.3(22/5):
The actual loop body procedure passed to an explicit call of a subprogram for which the Parallel_Iterator aspect is True shall have a Parallel_Calls aspect True.
!discussion
None.
!ASIS
None.
!ACATS test
ACATS B-Tests are needed to check that the new rules are enforced. One could imagine a C-Test that Parallel_Calls works, but that is the normal case for a parallel procedural iterator, so any test will check that.
!appendix

From: Tucker Taft
Sent: Monday, August 19, 2019  8:46 PM

I believe we have a bug in the legality requirement for Allows_Exit and
Parallel_Iterator aspects.  It currently says that the callable entity 
shall have at least one parameter of an anonymous access-to-subprogram type.  
I don't think that really makes sense.  I think we should say "exactly one" 
because otherwise how do we know which parameter is the "loop body procedure"
which is mentioned in the description of the semantics of the aspects.

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

From: Steve Baird
Sent: Tuesday, August 20, 2019  3:55 PM

Makes sense.

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

From: Tucker Taft
Sent: Wednesday, August 21, 2019  6:37 PM

The latest version of AI12-0326-2 introduces the Parallel_Iterator aspect as
part of a parallel procedural iterator.  If you explicitly call a procedure 
with Parallel_Iterator => True rather than as part of a parallel procedural 
iterator, it seems that we might want to impose a requirement on the procedure
passed as an access-to-subp parameter (which corresponds to the "loop body 
procedure" created implicitly by the compiler).  

My suggestion is that we require that this procedure have aspect 
Parallel_Calls => True.  This will indicate that the programmer recognized 
this routine would be called in parallel, and would cause the compiler to 
check that this procedure can safely be called in parallel with itself, 
i.e. re-entrantly, if required by the Conflict_Check_Policy in effect at the 
point of declaration.  Even if no conflict checks are being performed, the 
presence of this aspect would indicate the programmer knew (and the reader 
will learn) it might be used in such a context.

When the compiler implicitly creates such a "loop body" procedure, it can 
also implicitly set Parallel_Calls => True. 

This came up because I am doing hand-expansions of various examples that use 
parallel procedural iterators, and it seemed odd that there was no checking 
implied.  I suppose we could liberalize this a bit to say that either 
Parallel_Calls => True, or any Global beyond "null" is synchronized.

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



Questions? Ask the ACAA Technical Agent