Version 1.1 of 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