(j3.2006) (SC22WG5.5345) Preliminary result of the WG5 straw ballot on N2027

[John Reid]

Robert Corbett wrote:
> On 09/16/14 06:24, John Reid wrote:
>> Whoops! Bill points out that I overlooked Bob's vote. I am very sorry,
>> Bob. Here is a revision.
>
> You were closer to correct before the revision.  My vote was 4) Abstain,
> not 1) Yes.
>
> Bob Corbett


Oh dear! How could I be so careless? Here is a third try.

Sorry,

John.
-------------- next part --------------
                                           ISO/IEC JTC1/SC22/WG5 N2031-3

             Result of the WG5 straw ballot on N2027

                         John Reid

N2028 asked this question

Please answer the following question "Is N2027 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.

The numbers of answers in each category were:
3 for 1) Yes (Chen, Moene, Nagle)
5 for 2) Yes, but I recommend the following changes
         (Bader, Long, Reid, Snyder, Whitlock)
1 for 3) No, for the following reasons (Maclaren)
2 for 4) Abstain (Corbett, Muxworthy)

The ballot has passed, but all the comments needed to be considered.  
I request J3 to prepare a revised version for final approval by WG5 
and submission to SC22 for PDTS ballot in November 2014.

Here are the comments and reasons:

Reinhold Bader

[14:5-7]
There are some implications of recovering stalled images which I 
believe must be accounted for. Before control is transferred to the
END TEAM, on each level of the call stack that is traversed, 
* allocated variables that go out of scope must be deallocated; 
  for allocatable coarray variables presumably no synchronization 
  should be required in this special situation (images of the team
  that do not stall should do the synced deallocation fine given 
  [33:31-32]).
* finalizers for objects that go out of scope must be invoked.

Further state may exist for which no explicit cleanup can be
performed by the implememtation's run time (anonymous pointer 
targets, open I/O units, some or all of which may become orphaned). 
Perhaps something one might call an internal final procedure can be 
defined that allows the programmer to deal with these? Such a 
procedure could only be implicitly invoked in this special situation.  

[17:25]
"INTENT(IN) argument" appears inappropriate for ATOMIC_REF and
EVENT_QUERY. I suggest rewording this as "evaluation of or 
assignment to an object that is not an ATOM or EVENT argument".

[17:32+] / NOTE 7.2
The TS defines the notion of asynchronous progress in 3.1, but
no reference to that term is made in normative text. While there
seems to be agreement to defer this to the integration with the
standard, some additional NOTE here, or text in the Appendix A.3.2,
that indicates what is expected of implementations would be welcome.

[18:27+] / NOTE 7.5
After "The rules of Fortran" add a reference 
(presumably to section 12.5.2.13 of ISO/IEC-1539-1:2010).

[23:27+]
Tobias Burnus has pointed out that there may be significant
difficulties to implement CO_REDUCE for the case that the argument A
is of a type with POINTER or ALLOCATABLE components. I have not had
the time to think the implications through, but I suggest addition of 
suitable restrictions or constraints if J3 agrees there is a problem.

[25:31-35]
This appears to be in contradiction with [36:1-2]. A weakening of 
the requirement in [36:1-2] however would seem to imply that the call 
to FAILED_IMAGES in the A.1.2 example at [44:27] is unlikely to deliver 
the correct result. Therefore I prefer that the requirement here be 
strengthened.

[29:12-22] 
Given that the TS now has FAILED_IMAGES, I think the FAILED argument 
can be removed from the function NUM_IMAGES. If this suggestion is not 
followed, some wording changes are needed to refer to "images known to 
be failed" instead of "failed images". Corresponding edits needed in
[39:1], [39:9-10], [39:14-16].

_______________________________________________________________________

Bill Long

-- The statement in 7.2p4 that the ATOM argument becomes undefined if
   an error condition occurs is wrong for ATOMIC_REF, where the ATOM
   argument is INTENT(IN) and hence prohibited from becoming
   undefined. For ATOMIC_REF, the VALUE argument is the one that
   becomes undefined. That is currently covered separately at
   [38:9]. The text in 7.2p4 needs to exempt ATOMIC_REF. Optionally
   the case covered at [30:9] text could be moved to 7.2p4 so that the
   consequences of an error condition are located together.  Edits
   needed at [17:28-29] and possibly [38:9].

-- I find NOTE 7.1 confusing and contradictory. A failed image is one
   for which accesses fail (See 3.4). How can it be indeterminate
   whether a call that involves access to a failed image fails? I
   would prefer to just delete this NOTE.

-- The first para of 7.3 says that collectives are performed over the
   nonfailed images of the current team. That implies that the
   operation can be successful even if there are (ignored) failed
   images in the team. However, the case of STAT returning
   STAT_FAILED_IMAGE is covered in 7.3p5 which describes what happens
   if an error condition occurs. To be consistent with 7.3p1, the
   wording in 7.3p4 needs to be changed to include the failed image
   case there. The last sentence of 7.3p5 needs to be removed, "or
   STAT_FAILED_IMAGE in the intrinsic module ISO_FORTRAN_ENV" removed
   from the previous sentence, and 7.3p4 modified by changing ???the
   argument is assigned the value zero??? to ???the argument is assigned
   the value zero if no image in the current team is known to have
   failed and STAT_FAILED_IMAGE otherwise???.  Additionally, since it is
   unusual for a non-zero STAT to indicate success, it would be
   helpful to further explain this situation in a NOTE 7.5+.  Edits
   needed at [18:13-14], [18:20-22], and [36:29] (remove "the first").

-- The descriptions of STAT and ERRMSG arguments in 7.3 are
   inconsistent in style. For STAT, we have "... is assigned the value
   zero", whereas for ERRMSG we have "... the processor shall assign
   ..." and "...the processor shall not change...". The STAT form is
   more consistent with other descriptions of the actions of intrinsic
   procedures. Edits needed at [18:26] and [18:27].

-- The EVENT_QUERY subroutine was changed to be an Atomic subroutine in
   this draft. The other Atomic subroutines do not have ERRMSG
   arguments. It would be more consistent to remove the ERRMSG
   argument from EVENT_QUERY. Edits needed at [24:37], [25:6-8],
   [37:1-].

_______________________________________________________________________

Nick Maclaren

There is still too much substantive discussion of and uncertainty
about the required semantics, and associated details.

The image failure feature is something which has never been standardised
successfully in any programming language or portable library.

Many of the examples (specifically those using EVENT_QUERY, but also
some of those using the atomic subroutines) depend on semantics that
are not derivable from the normative text.

That might be acceptable for a free-standing TS, but the current plan is
that this TS is due to be integrated into the standard without waiting
for user experience.

There may also be problems of detail, but I have not had time to check
for them.

_____________________________________________________________________

Dan Nagle

I agree with Bill's and John's comments.
______________________________________________________________________

John Reid

[5:11+] Add
"<3.2a>
<established coarray>
coarray that is accessible within a CHANGE TEAM construct from outside 
the construct (5.1)"
Reason: The term "established" is used quite a bit. I think we need a 
definition.

[5:32+] Add
"<3.4.1>
<known failed image>
image known by the executing image to have failed (5.8)"

[10:27] Change 
"a coarray that does not appear in a <coarray-association>"
to
"a coarray that is not an associating entity".
Reason. The present wording suggests that a coarray established outside
the construct is not accessible if it appears in a <coarray-association>.

[13:5] After "image M" add "since execution last began in this team".
Reason. In an earlier execution as a team, an image might have failed
temporarily because of the failure of another image. 

[13:20] After "SYNC TEAM statement" add "or the STAT argument in an
invocation of a collective procedure". 
Reason: This case seems to have been overlooked.

[14:7+] Add paragraph
"If the executing image detects that another image has failed by 
executing an image control statement whose STAT= specifier is assigned 
the value STAT_FAILED_IMAGE or invoking a collective or atomic 
subroutine whose STAT argument is set to STAT_FAILED_IMAGE, the other
image is known by the executing image to have failed. If the failure 
has occurred as described in the previous paragraph, the image ceases 
to be known as having failed after execution of the relevant END TEAM  
statement."
Reason. We need a clear definition of the term "known failed image". It
is currently buried in the result value paragraph of 7.4.16 FAILED_IMAGES.

[16:17-20+] Swap the text of Note 6.3 with the text of the paragraph in 
lines 17-20.
Reason. The text in the paragraph seems unsuitable to be definitive 
text. It is the sequence of changes of the value of the event variable 
that matters, as given in the note. 

[17:19] Change "atomic memory operations" to "atomic actions".
Reason. This is the terminology that we are using, see earlier in this 
paragraph.

[17:32+] In NOTE 7.1, line 1, after "atomic subroutine" add 
"without a STAT argument". 
Reason. I think the intention is for the call to be lightweight and fast 
if there is no STAT argument but to make a check that all is well with 
the image if STAT is present.

[18:14] After "zero" and "if no image in the current team is detected 
as failed and STAT_FAILED_IMAGE otherwise".
Reason: We need to regard a collective as successful even if it detects
failed images, see [18:2-3]. 

[18:21-22] Delete sentence "If an ... STAT_FAILED_IMAGE."
Reason: We need to regard a collective as successful even if it detects
failed images, see [18:2-3]. 

[19:25] Change "bitwise AND" to "atomic".
[19:38] Change "compare" to "atomic".
[20:4] Change "compare and swap" to "atomic".
[20:15&19] Change "add" to "atomic".
[20:30&34] Change "bitwise AND" to "atomic".
[21:5&9] Change "bitwise OR" to "atomic".
[21:20&24] Change "bitwise exclusive OR" to "atomic".
[21:36] Change "bitwise OR" to "atomic".
[22:9] Change "bitwise exclusive OR" to "atomic".
Reason. In all these cases, it is the atomic nature of the operation 
that is important. What is done has already been stated. 

[22:11, 22:16, 22:24, 22:31, 22:33, 22:40, 22:42, 23:11, 23:13, 23:20, 
23:22, 23:33, 23:36, 23:40, 23:42 twice, 24:3, 24:5, 24:21, 24:23, 
24:30, 24:32] Add "nonfailed" before "images".
[22:26, 23:6, 23:28, 24:15] Change "current team of images" to 
"nonfailed images of the current team".
Reason. Consistency with 7.3 para 1. 

[22:20, 22:38, 23:18, 24:1, 24:28, 25:5, 28:28] Delete "default".
Reason: We do not need to require these STAT arguments to be of type
default integer. 

[24:37] Delete ", ERRMSG".
[25:6-8] Delete "ERRMSG ... the argument."
Reason. None of the other atomic subroutines have an ERRMSG argument. 

[25:31-35] Delete sentence "If the executing image ... failed."
Reason: Let's instead have a clear definition in 5.8.

[27:20] Before "have initiated" add "are known to".
[27:25] Before "have initiated" add "be known to".
[27:26] Change "has initiated" add "is known to have initiated".
[27:27] Before "have initiated" add "are known to".
Reason: This should be like FAILED_IMAGES and only list the images it
already knows have stopped. 

[29:21-22] Change
"number of failed images in the team specified, otherwise the result is 
the number of nonfailed images in the team specified" 
to
"number of images in the team specified that are known to have failed, 
otherwise the result is the number of images in the team specified that
are not known to have failed".
Reason. NUM_IMAGES should use the list of failed images that the image
has. 

[31:24] Change "which" to "that". 
Reason. The STAT value STAT_FAILED_IMAGE just indicates that an image 
has failed and FAILED_IMAGES only lists the images the executing image
already knows have failed. 

[31:26 to 32:27] Replace by
"{In 1.3 Terms and definitions, insert the new terms of Clause 3 of this
Technical Specification.}"
Reason. It is safer to define the terms once in the TS. 

[35:13] Replace  "as many times as has image M" by 
"{\ul in the current team} as many times as has image M 
{\ul since execution last began in this team}".
Reason. On leaving a CHANGE TEAM construct, we need to ignore the 
SYNC ALLs executed within it because their numbers may differ. 

[35:16] Change "3" to "4".
[35:21+] Add para:
"Execution of a SYNC IMAGES statement performs a synchronization of the 
image with each of the other {\ul nonfailed} images in the <image-set>. 
Executions of SYNC IMAGES statements on images M and T correspond if
the number of times image M has executed a SYNC IMAGES statement 
{\ul in the current team} with T in its image set {\ul since execution 
last began in this team} is the same as the number of times image T has 
executed a SYNC IMAGES statement {\ul in the current team} with M in 
its image set {\ul since execution last began in this team}. The 
segments that executed before the SYNC IMAGES statement on either 
image precede the segments that execute after the corresponding
SYNC IMAGES statement on the other image."
Reason. We need to allow for failed images in SYNC IMAGES in just the
same way as in SYNC ALL. Note that both are mentioned in 5.8 at 
[13:20].

[37:1-] In the entry for EVENT QUERY, Delete ", ERRMSG".
Reason. None of the other atomic subroutines have an ERRMSG argument. 

[38:3] After "description" add "and a paragraph".
[38:4+] Add "if an error condition occurs, the ATOM argument becomes
undefined".
Reason. We do the equivalent for ATOMIC_REF.

[39:10] Change "failed ... nonfailed images" to "images in the team 
specified that are known to have failed or the number that are not 
known to have failed". 
[39:15-16] Change "failed ... specified" to "images in the team 
specified that are known to have failed; otherwise, the result is the
number that are not known to have failed". 
Reason. NUM_IMAGES should use the list of failed images that the image
has. 

[40:15+} Add
"{In 13.8.2.24 STAT_STOPPED_IMAGE, insert new paragraph after 
paragraph 1}
If the executing image detects that another image has stopped by 
executing a statement whose STAT= specifier is assigned 
the value STAT_STOPPED_IMAGE or invoked a collective or atomic 
subroutine whose STAT argument is set to STAT_STOPPED_IMAGE, the other
image is known by the executing image to have stopped. "
Reason. We need a clear definition of the term "known stopped image".


_______________________________________________________________________

Van Snyder

Most of my comments are editorial, but a few are substantive.  I believe
the substantive ones can be addressed easily.

1. Substantive:

[10:14+] A constraint is apparently needed:

"C507a (R503) A <coselector-name> shall be the name of an accessible
       coarray."

Why is the STAT argument to the new and revised intrinsic procedures a
default integer?  It's not a default integer in ALLOCATE, DEALLOCATE,
<sync-stat>, i/o statements....

[22:20 22:38 23:18 24:1 24:28 25:5 28:28 38:29] Replace "a scalar of
type default integer" or "a scalar and of type default integer" with "an
integer scalar".  If it's important to be a default integer, replace "a
scalar of type default integer" or "a scalar and of type default
integer" with "a default integer scalar".

[25:21 29:17 38:19 39:6 39:24] If there is no problem with TEAM
representing the current team, replace "ancestor" with "current or
ancestor".

[35:40-42] Isn't the image that executes the SYNC IMAGES, LOCK, UNLOCK
or EVENT POST statement involved?  If so, replace the sentences with
something like "In addition to the image that executes a SYNC IMAGES
statement, the other images specified in its <image-set> are involved. 
Other than the image that executes a LOCK or UNLOCK statement, the image
on which the referenced lock variable is located is involved.  Other
than the image that executes an EVENT POST statement, the image on which
the referenced event variable is located is involved."

2. Editorial:

2.1. General

The standard usually uses "shall be of type..." instead of "shall be of
the type..."

[10:13 25:20 25:23 27:14 27:32 28:20 29:16 29:27 38:18 39:5 39:23]
Delete "the" before "type"

The standard usually uses "object of type" or "a scalar of type" instead
of "object and of type" or "object and of the type" or "scalar and of
type".  The TS uses both.  Only the former should be used.

[19:6 19:18 19:30 20:9 20:24 20:39 21:14 21:29 22:2 26:7] Delete "and".

[19:10 19:22 21:33 22:6 25:2] Replace "scalar and of type integer" with
"an integer scalar".

[19:37 19:39 19:40 24:41] Replace "scalar and" with "a scalar".

The standard usually uses "default character scalar" instead of "scalar
of type default character".

[22:21 22:39 23:19 24:2 24:29 25:6 28:29 38:30] Replace "scalar of type
default character" with "default character scalar".

Sometimes "image of ... team" is used, sometimes "image in ... team" is
used.  Using "image of ... team" makes one wonder "What is an image of a
team?  I thought we only had images of programs."  Use "image in ...
team" throughout.

[22:16 22:19 22:33 22:36(twice) 22:37 22:40 22:42 23:12 23:16(twice)
23:17 23:31 23:33 23:34 23:36 23:40 23:42(twice) 23:43 24:3 24:5 24:18
24:21(twice) 24:26(twice) 24:27 24:30 24:32 33:2 34:25 34:25]
Replace "of the current" with "in the current".

[32:38 32:39 36:18] Replace "of" with "in".

2.2. Specific

[iv] Introduction paragraph 1, line 2: Delete "a set of".
[iv] paragraph 3, line 5: Delete "sets of".
[5:2] Delete first "the".
[9:4] Replace "have been" with "are" or "are here".
[9:15] Replace "block" with "construct".
[10:30] Delete "the".
[10:40] Delete "the" before "other".
[11:Note 5.3, line 1] Insert "image" after "Each".
[11:Note 5.3, line 6] Append ", ONLY: TEAM_TYPE".
[12:18] Replace "it shall be executed by the same statement" with "the
same statement shall be executed".
[14:4] Replace "are" with "shall be".
[14:Note 5.8, lines 3-4] Replace "may" with "might" because ISO rules do
not allow requirements or permissions in nonnormative text.
[15:13] Replace "INTEGER with KIND of ATOMIC_INT_KIND defined" with
"integer with kind ATOMIC_INT_KIND, where ATOMIC_INT_KIND is a named
constant". (compare with 7.4.1 ATOM argument description).
[15:28] Insert a blank before the left parenthesis.
[15:32] Delete "the" before "execution".
[16:6] Insert a blank before the left parenthesis.
[16:11] Replace "UNTIL_COUNT ... with" with "<scalar-int-expr> if
the UNTIL_COUNT specifier appears and <scalar-int-expr> has".
[17:Note 7.1, line 1] Replace "for" with "with an actual argument that
is" (what does executing a subroutine for an object mean?).
[17:Note 7.2, line 1] Replace "These properties" with "The properties of
atomic subroutines".
[18:Note 7.3, line 1] Replace "in the event ... for" with "if an error
condition occurs during execution of".
[18:Note 7.4, line 1] Replace "collectives" with "collective
subroutines".
[18:Note 7.5, line 1] Replace "procedure" with "subroutine".
[18:Note 7.5, line 2,5,6] Insert "subroutine" after "collective" thrice.
[20:34] Insert "was" before "executed".
[23:40] Replace "implement" with "be".
[25:23] Insert "decimal" before "range".
[25:32-33] Insert a comma after "STAT_FAILED_IMAGE" twice.
[26:5] Replace "and" with "or".
[26:15] Append ", ONLY: TEAM_TYPE".
[26:22] Append ", ONLY: TEAM_TYPE".
[27:14] Insert "decimal" before "range".
[27:24] Replace "image in the set of" with "of the".
[29:4] Insert "of the named constant" before "STAT_-".
[29:11] Replace "such" with "error".
[29:19] Delete "the" before "execution".
[29:22] Replace the comma with a semicolon.
[31:19] Delete "powerful".  Belongs in a sales brochure.
[31:21] Delete "tagged" (the term is not defined anywhere).
[33:5] Insert "being" (with underwave) before "defined".
[33:8] Delete the space between "LOCK_TYPE" and the comma.
[33:18] Insert a comma before "or" twice.
[34:4] Insert "in the current team" after "images".
[34:5] Insert "of the named constant" before "STAT_STOPPED_IMAGE".
[34:10] Insert "named" before "constant".
[34:12] Replace "value of" with "values of the named constants".
[35:28] Insert "of the named constant" before "STAT_FAILED_IMAGE".
[35:32] Insert "value of the named" before "constant".
[35:35] Replace "value of" with "values of the named constants".
[35:39] Delete "argument" (statements don't have arguments).
[37 in the list of new entries for the table in 13.5, for EVENT_QUERY]
Insert "variable" after "event".
[39:9] Replace "scalar of type LOGICAL" with "logical scalar" (compare
MASK argument to ALL in 1539).
[41:11-16] Need subclause numbers.


_______________________________________________________________________

Stan Whitlock

 I agree with John Reid?s ballot comments.