!standard 5.5.3(16/5) 20-01-12 AI12-0344-1/02 !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-subprogram parameter. Aspect Parallel_Calls is defined to check that a subprogram 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 subprogram 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 Add after 5.5.3(15/5): In a procedural iterator, the Parallel_Calls aspect (see 9.10.1) of the loop body procedure is True if the reserved word *parallel* occurs in the corresponding loop statement, and False otherwise. Modify 5.5.3(16/5): The following aspects may be specified for a callable entity S that has {exactly}[at least] one formal parameter of an anonymous access-to-subprogram type: Add after 5.5.3(22/5): If the actual parameter of an anonymous access-to-subprogram type, passed in an explicit call of a subprogram for which the Parallel_Iterator aspect is True, is of the form P'Access, the designated subprogram P shall have a Parallel_Calls aspect True (see 9.10.1). Add after 9.10.1(22/5): The following aspect can be specified for a subprogram 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 subprogram is True if Parallel_Calls is True either for the corresponding subprogram of the progenitor type or for any other inherited subprogram that it overrides. If not specified or inherited as True, the Parallel_Calls aspect of a subprogram is False. Specifying the Parallel_Calls aspect to be True for a subprogram indicates that the subprogram can be safely called in parallel. Conflict checks (if required by the Conflict_Check_Policy in effect) are made on the subprogram assuming that multiple concurrent calls exist. [Redundant: Such checks need not be repeated at each call of the subprogram in a parallel iteration context.] !discussion As indicated in the !problem, to prevent ambiguity, we limit the aspects Allows_Exit and Parallel_Iterator to subprograms with a single parameter of an anonymous access-to-subprogram type. We allow both access-to-function and access-to-procedure parameters, as these capabilities might be relevant in constructs where a function rather than a procedure is being called repeatedly. (Such as a parallel aggregate, if such a thing exists.) We add a new aspect, Parallel_Calls, to apply to subprograms that are expected to be called by a subprogram with the Parallel_Iterator aspect, or to be called in other parallel iteration contexts. Such a subprogram is checked according to the Confict_Check_Policy in effect, to determine whether it can be safely called concurrently. This enables some conflict checking to be performed modularly, without relying on a specified Global aspect. !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. **************************************************************** From: Brad Moore Sent: Saturday, August 24, 2019 10:52 PM >> ... >> My reasoning for having the Process parameter first is that all my >> library calls have a Process parameter. >> It is the only common parameter, so it makes sense to have it as the >> first parameter for consistency. > > The proposed syntax for the procedural iterator allows you to omit the > "<>" if the "process" parameter is last, which is the reason I put it last. [The above quote is from a thread filed in AI12-0357-1. - Editor.] And from another recent email.... > 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. My question is, if we are changing this to only allow "exactly one" parameter of an anonymous access-to-subprogram type, then it seems a bit of a weird restriction that it has to be the last parameter to allow omitting the <>. If there can only be one such parameter, why not allow omitting the <> regardless of which parameter it is? **************************************************************** From: Tucker Taft Sent: Sunday, August 25, 2019 7:47 AM Interesting point. Worth discussing at the ARG meeting, if not before. I was suggesting it being a requirement only when Allows_Exit or Parallel_Iterator is specified True, but it is not a big leap to make it a general requirement for any use of the procedural iterator. ****************************************************************