(j3.2006) (SC22WG5.5131) Vote on revised draft DTS

[Bill Long]

                                           ISO/IEC JTC1/SC22/WG5 N1997

                        WG5 letter ballot on N1996

                         John Reid, 7 November 2013

This is a WG5 letter ballot on N1996, the third draft DTS for
TS 18508, Additional Parallel Features in Fortran.

N1996 has the same content as J3/13-358. It was prepared by the editor,
Bill Long, following the recent meeting of J3. Details of the changes
made from the previous draft, N1983, are given in J3/13-359.

The basic requirements were changed during the WG5 meeting in Delft and
are given in N1981, which supersedes N1930.

Please answer the following question "Is N1996 ready for forwarding to
SC22 as the DTS?" in one of these ways.

1) Yes.
2) Yes, but I recommend the following changes.
3) No, for the following reasons.
4) Abstain.


No, for the reasons in the attached file.

Cheers,
Bill



-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101


-------------- next part --------------
Response details  from Bill Long on Ballot N1997.

I. Minor editorial fixes.
-------------------------

1) In 5.3, [10:17] delete "scalar".  {The rule R504 for a team
variable already says "scalar", so it is redundant here.}

2) In 5.3 the paragraph at [10:22-23] effectively prohibits
deallocation of a team variable for an active team construct. This
seems to make [9:34] redundant. Propose to delete [9:34].

3) In 5.4 Note 5.2 line 1, "A(0,N+1)" -> "A(0:N+1)".

4) In 5.5 [11:15] delete "It is an image control statement." and
insert "The FORM TEAM statement is an image control statement." at the
beginning of [12:1]. The merge the paragraphs [12:1-2] and
[12:3-6]. {Move image control statement bit to para where we discuss
the meaning.  Parallel to other subclauses describing statements that
are image control statements.}

5) 5.5 Note 5.4 line 1, replace "coarrays regarded" with
"corresponding coarrays on each image representing parts of a larger
array".  {Avoid potential confusion about coarrays being global
objects.}

6) 5.7 Note 5.7 line 2, delete "on modern hardware".  {The word
"modern" becomes dated, inconsistent with the nature of a standard.}

7) In 6.3 [15:29] replace "event variable's count" with "count of the
event variable". {Parallel wording to EVENT WAIT.}

8) In 7.1 [17:8] replace "intrinsics" with "intrinsic procedures". 
{Subroutines and functions are pure, not 'intrinsics'.}

9) In 7.4, for the OLD arguments at [18:19], [19:6], [19:37], [20:10],
replace "shall be a scalar of type integer with the same kind as ATOM"
with "shall be a scalar and of the same type and kind as
ATOM". {Wording more like ATOMIC_CAS, and allows for future
possibility that additional types are allowed for ATOM.}

10) In 7.4.3 [19:27], replace "prior to the comparison" with "used for
performing the comparison operation". {Clearer and more like similar
wording in other examples.}

11) In 7.4.9 [22:33] replace "continues until" with "terminates
when". {Possibly clearer - current text is not specific about what
more might happen.}

12) In 7.4.13 [24:19], replace "The corresponding actual argument"
with "It". {The argument descriptions for intrinsic procedures are for
the actual arguments. See f2008 [325:5-6].}

13) In 7.5.2 [26:27] after "image index" insert "of the invoking
image". {Clarification}

14) In 8.11 [33:27-28] replace "function" with "subroutine"
twice. {From Dan email.}

15) Noted misc fixes in Reinhold's ballot at [36:15], [36:36], [37:36]
and [37:37], all of which appear valid.



II. More significnant fixes/questions.
--------------------------------------

1) In 2 Normative reference, do we need to include references to the
Corrigenda?  If we do, how does this affect the Edits clause?

2) In 5.2 [9:34] could be clarified to begin "The team variable
specified in the CHANGE TEAM statement of the current change team
construct...shall not be deallocated."  {It is possible for there to
be multiple team variables with the same value. Ones not appearing in
an active CHANGE TEAM statement should be OK to deallocate.} Note: See
I-2 above. If that is accepted, this edit is moot.

3) In 5.4 [11:1-4] replace the first sentence of the para with "If
<team-variable> appears in an image selector its value shall be the
same as the team variable specified in the CHANGE TEAM statement of a
currently executing change team construct or the initial team. The
image index computed using the specified cosubscripts is interpreted
as an image index in the team specified by <team-variable>."  {The
wording about FORM TEAM and GET_TEAM is duplicated in [10:19-21].
Furthermore, the original text was unclear that the value relative the
the team is the image index.}

4) In 5.7 [12:24] Is the term "collective activity" well defined?

5) In 5.7, after Note 5.7, should we include a note saying that
continued execution can depend on the nature of the program/algorithm?

6) Subclause 6.5 might not be needed at all depending on the outcome
of the discussion on MAX_COUNT.

7) In 7.3 [17:28-29] This para is overkill.  It is allowed, for
example, that the VALUE argument be a coarray, and there is no such
requirement in that case. You could also have a coarray STAT
argument. Needs to be restricted to the argument on which the
collective operation takes place.

8) In 7.4, in the descriptions of the ATOMIC_* subroutines, we use the
"becomes defined with" terminology frequently. In other parts of the
document we have moved to "is assigned". Do we want these changed as
well?

9) In 7.4.9 CO_REDUCE [22:16] the statement "and the function shall be
executed by all images of the current team" is not true. It is
allowed, for example, for just one of the images to do the whole
computation. We intend that, for any image that does execute the
function, it is the same function.

10) In 7.4.9 [22:17] Is it allowed for the RESULT argument to be
polymorphic? Seems not symmetric with SOURCE.

11) 7.4.11 [23:24] In EVENT_QUERY, there should be an ERRMSG argument
as well. Compare with the GET_xxx intrinsics.

12) In 7.4.13 [24:19-20], is the sentence "The corresponding
... ancestors." needed? The sentence is poorly worded, and redefining
what is actually intended here is already prohibited elsewhere.
Propose to delete rather than repair. If that is accepted, I-12 above
is moot.



III. Issues not yet resolved.
-----------------------------

1) The MAX_COUNT feature in EVENT POST has problems (expanded from
   13-359).

The intention is that operations on the count variable of an event be
atomic. That is easy for a plain EVENT POST (atomic add 1) and EVENT
WAIT (atomic add -1).  This also is the case for an EVENT POST with a
COUNT= specifier (atomic fetch-and-add 1) which would provide
potentially useful information to the executing image. Similarly, and
EVENT CLEAR statement could be implemented as (atomic and
0). Alternatively, an EVENT CLEAR could be implemented as an EVENT
WAIT with a CLEAR="yes' qualifier, for example.  Or, with richer
semantics as an EVENT WAIT (UNTIL_COUNT = <scalar-int-expr>) form that
would wait until the count got to the indicated level and then
subtract the UNTIL_COUNT value from the event variable count and
complete. These alternatives need consideration, as they provide
useful functionality and can still be implemented atomically.

However, including a MAX_COUNT specifier in an EVENT POST statement
can lead to a race condition. This is fundamentally two operations - a
fetch of the current value, followed by a decision on whether to
increment.  It is possible to get around this with repeated retries
with a compare-and-swap operation, but the implementation will be
significantly slower and potentially deadlock. Therefore, I think the
current MAX_COUNT= specifier is problematic and needs repair or
removal.  Note that there is a special case that would work - a binary
only version that only sets the count to 1 if it is currently 0
(atomic compare-and-swap). As long as the user never executes a
'non-binary' event post on that event variable this could be usable.
That involves either restricting MAX_COUNT to be 1 if it is specified,
or to change the spelling to something line BINARY='yes', with the
default 'no'.


2) EVENT QUERY loose ends (from 13-359).

In 7.4.11 EVENT_QUERY, the COUNT argument is assigned the value 0 if
an error occurs. Not very informative. Perhaps count=-1 would be more
useful in the error case.

In 7.4.11 EVENT_QUERY, if the STATUS argument is not present and an
error condition occurs, does the program terminate? It appears
not. That is the same as for GET_COMMAND and friends with a STATUS
argument. But the opportunities for failure here are greater (EVENT
image is failed, for example).  Should a valid value be
STAT_FAILED_IMAGE?


3) Deallocation of a saved coarray at the end of a CHANGE TEAM
   construct (from 13-359).

Note 5.1 explains that an implementation is responsible for
deallocating coarrays at the end of an CHANGE TEAM construct. This is
not trivial, since a coarray with the SAVE attribute that is allocated
in a subprogram called will need to be tracked by the runtime in case
the subroutine is called inside a CHANGE TEAM construct. No suggestion
for a change - just a heads up to implementors.


4) Do we want a cobounds remapping facility?  This would be a new
   feature.  Background and discussion follows.


In N1996, the TS 18508 draft from J3 meeting 202, the facility
provided by the modified image selectors allows references to coarrays
on images that are not part of the current team. This is enabled by
syntax that specifies a different team that is in effect for that
reference.  The team has to be an ancestor of the current team, and
include the image specified. 

The cobounds for a coarray can only be specified in a declaration or
allocate statement. Changing to a different team does not alter the
cobounds or corank of an existing coarray. A coarray has only one set
of bounds at a given time, and only allocatable coarrays can change
their cobounds during program execution.

The identification of the correct physical PE containing the coarray
being referenced using the new syntax involves two steps: Using the
specified cosubscripts and the current cobounds for the coarray, an
image index is computed. The image index is then converted to a
physical PE by a team-specific mapping.

Suppose a coarray, 

   REAL :: A(:)[N1,N2,*] 

exists (either static, or allocatable and allocated with those
cobounds) on each image on entry to a CHANGE TEAM construct. For
statements executed during execution of the CHANGE TEAM construct:

Case 1: No team is specified in the reference:

   X(:) = A(:)[i,j,k]
 
This reference is relative to the current team. The cobounds used to
compute the image index are the ones that existed when the CHANGE TEAM
construct began.  If the computed image index is outside the range
1..num_images() for the current team, the reference is in error. If
the image index is in the valid range, the mapping between image
indices and physical PE for the current team is used to identify the
physical PE containing the referenced coarray.  The computation of the
correct coarray location is unambiguous in this case, though the
selection of the values [i,j,k] might not be intuitive.


Case 2: An ancestor team, pteam, is specified in the reference:

   X(:) = A(:)[pteam :: i,j,k]

This reference is relative to the team specified by the value of the
team variable pteam. The computation of the image index is exactly the
same as in Case 1, with the current cobounds of A(:) used.  The value
of num_images() used in the range check for a valid image index is the
number of images in team pteam. The image identified has to be an
image that is part of team pteam; otherwise an error occurs.  The
mapping between the computed image index and a physical PE location
for A is the one for team pteam.

For the team-modified image selector syntax to work, the
implementation would need to keep track of the mapping and
num_images() information for all ancestors of the current team, and
associate that with the team variable. This is probably the case
anyway. It is not necessary to keep track of cobound information
separately for each team - that information is tied to the coarray,
not the team.

As noted in N1983, in the comments on the previous TS draft from Van
Snyder, the correct values for the cosubscripts in Case 1 are not
intuitive unless the corank is one. The existing team-modified syntax
in Case 2 does not address that problem.

A facility enabled by a RECODIMENSION statement has been discussed on
coarray-ts to address this problem.  A RECODIMENSION defines the
current cobounds for a coarray that exists during execution of the
construct and is associated with the previously existing coarray of
the same name. The cobounds and corank of the construct coarray may be
different from those of the existing coarray. The association is
similar to argument association. This is superior to actual argument
association in that a procedure call is not involved. How use of this
feature would affect the ability to access the corresponding coarray
on an image outside the current team (using a team-modified image
specifier) is not quite as clear.

Alternatively, a syntax similar to the associate construct, as
suggested by Van, could be employed. That has the advantage of using a
different name for the construct entity, which would permit use of the
original name for accesses outside the current team.