!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 Procedural iterator aspects !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. ****************************************************************