ISO/IEC JTC1/SC22/WG5 N2031 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: 2 for 1) Yes (Chen, Moene) 6 for 2) Yes, but I recommend the following changes (Bader, Long, Nagle, 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> 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> image known by the executing image to have failed (5.8)" [10:27] Change "a coarray that does not appear in a " 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 . [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 . 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 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, , 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 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 " if the UNTIL_COUNT specifier appears and 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 Reids ballot comments.