ISO/IEC JTC1/SC22/WG5 N2054 Result of the WG5 straw ballot on N2048 John Reid N2053 asked this question Please answer the following question "Is N2048 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: 6 for 1) Yes (Chen, Clune, Leair, Moene, Nagle, Whitlock) 3 for 2) Yes, but I recommend the following changes (Bader, Long, Reid) 3 for 3) No, for the following reasons (Cohen, Maclaren, Snyder) 2 for 4) Abstain (Corbett, Muxworthy) I request that the coarray email group, led by the Editor Bill Long, consider all the comments and prepare a set of edits as soon as possible. The ballot has passed. I request the coarray email group, led by the Editor Bill Long, to consider all the comments and prepare a revised version for submission to SC22 for PDTS ballot. Reinhold Bader My answer to the question "Is N2048 ready for forwarding to SC22 as the PDTS?" is 2) Yes, but I recommend the following changes. [11:16+] add new paragraph "If STAT= appears in a coarray designator, the variable specified shall not be associated with any other entity that appears in an expression containing a reference to the coindexed object, or in an expression that is the right hand side of an assignment to the coindexed object." Reason: I assume it is not intended that Y = A[i, STAT=status] * status A[i, STAT=status] = Z * status A[i, STAT=status] = B[j, STAT=status] are conforming. [11:16++] add new paragraph "If STAT= appears in a coarray designator for a coindexed actual argument, the variable specified is defined * when the invoked procedure completes if the corresponding dummy argument has INTENT (INOUT), INTENT (OUT) or unspecified intent, * when the invoked procedure starts execution if the corresponding dummy argument has INTENT (IN)." Reason: State clearly when the STAT argument becomes defined for this special situation, under the assumption that copying is always needed. [19:33-34] This seems inconsistent with the way the STAT= in coarray designators are now defined in the TS. If there is a reason why this rule is needed, it should probably be prohibited to specify STAT= in the designator for a coindexed actual argument of an atomic. If not, one might as well delete the separate STAT= argument of the atomics. [38:34+] add sentence "It is processor dependent which images are involved in execution of a SYNC MEMORY statement, beyond the image executing the statement." [44:20+] add bullet "* images involved in execution of SYNC MEMORY, beyond the executing image (8.5.7)." Reason: In N2048 nothing at all is said any more about which images are involved in execution of that statement. [48:20-39] Indent executable statements by 2. [48:40] Indent by 4. (Indentation on page 49 seems OK). [52:37+] Add line " IF (NC(I) > 0) THEN" [52:38-39] Add indentation [52:39+] Add line " END IF" Reason: for the case NC(I)==0 [18:15-16] implies that UNTIL_COUNT is 1, causing the program to hang. I already noticed this in an earlier draft, but it didn't make it into the vote. Sorry. _____________________________________________________________________ Malcolm Cohen Vote: NO. All major technical issues need to be addressed to change my vote from No. Terminology: ------------ (0a) MAJOR ISSUE: The term "current team" is a poor name. Apart from the fact that the word "current" is frowned upon by ISO, there is no unique "current team", each image has its own "current team". I think that "active team" would be better - it is more understandable that this is per-image. That this is a major issue is demonstrated by the need to talk about the "current current team" vs the "current team at the time of execution of the blah statement", etc. (Yes, the TS does not generally do this, but that's because it is not being rigorous enough to avoid ambiguity.) In the further edits below I am sticking with "current team", this is so as not to conflate other issues with the terminological ones. (0b) The term "team identifier" is a poor choice, as there is no expectation of uniqueness and the team thus identified varies dynamically. A better term would be "team number"; that is, it is more like an input/output unit number than it is like a unique identifier. (0c) The definition of "established coarray" is confusing, precisely what this term means is also confusing -- no fix proposed. (0d) In several contexts the concept of "sub-team" would be useful, in particular it might make some of the wording more accurate and/or less convoluted in places. I think we can just use that word without definition, or we could say something like "The sub-teams of a team are those teams which have that team as a parent team." (0e) There is a singular occurrence of "associating coarray", and two mentions of coarrays that are or are not an "associating entity" that does not say that these are "associating coarrays". I note that an associate-name can be a coarray, in which case its variable is an associating entity. But that is probably not intended to be an "associating coarray". So some better terminology or use of existing terminology seems to be required. Major Technical Issues: ----------------------- (1) The definition of "current team" is completely defective; "innermost" is meaningless in this context. Also, it needs to be qualified with "of an image", since each image has its own current team [5:23-24] 3.5.1 current team, replace definition with qualification and text as follows "\termqual{of an image} team specified by the most recently executed CHANGE TEAM statement of an active CHANGE TEAM construct, or initial team if no CHANGE TEAM construct is active". (2) The term "team identifier" is ambiguously and confusingly described: definition says it is an "integer value identifying a team" according to which, all members of a team must have the same team id, and implicitly if two images have the same team id they belong to the same team; the second of these is clearly false in general. Do we need the definition? Maybe (the term is used in several places); in which case it would seem that a simpler operational definition would work. "value specified by this image as the in the FORM TEAM statement for the current team" according to the TEAM_ID intrinsic: "If the specified team is the initial team, the result is -1; otherwise, the result value is the team identifier of the invoking image in the specified team." which sounds like a team can have images with differing team identifiers, contradicting the definition. There is no statement anywhere which actually says how the team identifier is determined; one might think that FORM TEAM would do that, but it does not. As mentioned above I would prefer a term like "team number", but in any case it needs more careful and not internally contradictory description. [5:33] 3.5.4 team identifier, replace definition "integer value identifying a sub-team of a parent team" {See comment above on using "sub-team".} (3) 5.1p2 regurgitates the definition of "current team", which if we follow the ISO guidelines makes it an empty tautology viz "The team that is specified in the CHANGE TEAM blah blah, is the team that is specified in the CHANGE TEAM blah blah." This should be written as explanation, not as empty consequences. (I note that an alternative approach would be to have the definition of "current team" be the explanatory one, and to specify here how it is changed and what the consequences are.) NOTE: This absolutely needs to be changed because the current text is nonsensical vis-a-vis "innermost". [9:10-11] 5.1 Introduction, p2, replace with "During execution, each image has a current team, which is only changed by execution of CHANGE TEAM and END TEAM statements. Executing a CHANGE TEAM statement changes the current team to the team specified by the , and execution of the corresponding END TEAM statement restores the current team back to its state immediately prior to execution of the CHANGE TEAM statement." {More wordsmithing probably useful, but I think this is better than simply repeating the definition tautologically.} (4) More FORM TEAM defects. "The FORM TEAM statement defines for a new team. The value of specifies the new team to which the executing image will belong. The value of team-id shall be positive and is the same for all images that are members of the same team." This is at best ambiguous. When FORM TEAM is executed by all active images of the current team, they are all on "the same team" but they are not necessarily giving the same value. Nowhere does it say that the specifies the "team identifier" (which is not unique, but that is a separate issue). Nowhere does it say that is assigns the a value that specifies the team that the image will belong to. [12:8-10] 5.5 FORM TEAM statement, p1, replace with something like: "The FORM TEAM statement creates one or more teams from the active images of the current team. The value of shall be positive. The team identifier of each new team is its unique value. Successful execution of FORM TEAM assigns the on each participating image a value that specifies the new team that the image will belong to." {This could use further wordsmithing, but is a start.} Minor Technical Issues: ----------------------- Problem: "current team" and "initial team" definitions are circular, in fact "initial team" is completely content-free. I am not convinced that we need a special term for the garden variety English "initial team" at all. Fix: [5:27] 3.5.2 initial team, delete or replace with the following: "team, consisting of all images, that began execution of the program". Problem: "parent team" definition is wrong (does not only apply to current team) and as the term is hardly used anyway, is unnecessary. Fix: [5:27-29] 3.5.3 parent team, delete. Problem: "failed image" definition is a regurgitation of the waffle from its subclause, is not properly grammatical, and is at best ambiguous and at worst wrong, since references or definitions of a variable do not fail - in fact they work as specified by the TS, even though the user might think this is somewhat mysterious behaviour. This needs to be replaced by a simpler definition. Fix: [5:36-38] 3.6 failed image, replace definition with "image that has ceased participating in program execution but has not initiated termination" {Just say what we mean without going into the details of what the consequences are.} Editorial fixes: ---------------- Many of the terms and definitions have defective definitions; these should all be noun clauses with no article. Also plural should be avoided. [5:6] 3.1 active image "An image" -> "image". [5:9-10] 3.2 asynchronous progress, replace with "ability of an image to reference or define a coarray on another image without waiting for that image to execute any particular statement or class of statement" {"require" is wrong, since that would entail a requirement being imposed by the standard, which is not what is meant here; and it should all be singular} [5:11-14] 3.3 collective subroutine, delete. {This definition is useless and uninteresting.} [6:1] 3.7 stopped image, "an image" -> "image". [9:2] 5.1 "Introduction" -> "Team concepts". {This is introductory matter explaining team concepts, so...} _____________________________________________________________________ Bill Long As noted by Van, the description of the CRITICAL statement is incomplete. Van's suggested rewording didn't distinguish between executing a CRITICAL statement (several images could have started doing that) and completing execution of the CRITICAL statement (which happens on the image we really care about, the one that starts executing the block). Also, I think it would be better to edit the base standard to put the STAT= and ERRMSG= description in 8.5.7 and have a reference to 8.5.7 in 8.1.5. Other image control statements use that convention. The following alternate wording was proposed by John, and I agree it addresses the issues. Edits to N2048: [16:5-7] Replace the sentence "In the CRITICAL ... execute the construct." by a new paragraph: "If the processor has the ability to detect that an image has failed, when an image completes execution of a CRITICAL statement that has a STAT= specifier and the previous image to have entered the construct failed while executing it, the specified variable becomes defined with the value STAT_FAILED_IMAGE from the intrinsic module ISO_FORTRAN_ENV. Otherwise, when an image completes execution of a CRITICAL statement that has a STAT=specifier, the specified variable becomes defined with the value zero. When an image completes execution of a CRITICAL statement that has an ERRMSG= specifier and assigns a nonzero value to the status variable of a STAT= specifier or would have done so if a STAT= specifier had appeared, the processor shall assign an explanatory message to the specified variable as if by intrinsic assignment." [37:4] Before "}" add 'After para 3, add a new para: "The effect of a STAT= or an ERRMSG= specifier in a CRITICAL statement is explained in 8.5.7."' [38:40] Before "}" add "the following paragraphs, then add the final paragraph of 6.3 CRITICAL construct of this Technical Specification.” ______________________________________________________________ Nick Maclaren No, for the following reasons: Not all objections in previous responses have been addressed (see N2045 and the documents it points to). We do not know if it is possible to specify a well-defined consistency model for either events or collectives when called from within functions. We do not know if it is possible to specify the semantics of a complete program if an image fails. We do not know if it is possible to specify a consistency model for the atomic operations that can be implemented with reasonable efficiency without hardware or operating system assistance. We know that there are differing views of the intent of all of those features, and it is therefore vanishingly unlikely that progress on integrating this TS into the main standard will be fast. It is almost certain that, if we proceed according to the schedule, the above aspects will differ between processors in ways that will make it very hard to write portable, or even reliable, programs. I would change my vote to abstain if this TS were not integrated into the next version of the standard. ___________________________________________________________________ John Reid At the Feb. meeting of J3, we did not complete the changes needed for when an image fails while executing a CRITICAL construct. I suggest these edits to N2048. [16:5-7] Replace the sentence "In the CRITICAL ... execute the construct." by a new paragraph: "If the processor has the ability to detect that an image has failed, when an image completes execution of a CRITICAL statement that has a STAT= specifier and the previous image to have entered the construct failed while executing it, the specified variable becomes defined with the value STAT_FAILED_IMAGE from the intrinsic module ISO_FORTRAN_ENV. Otherwise, when an image completes execution of a CRITICAL statement that has a STAT=specifier, the specified variable becomes defined with the value zero. When an image completes execution of a CRITICAL statement that has an ERRMSG= specifier and assigns a nonzero value to the status variable of a STAT= specifier or would have done so if a STAT= specifier had appeared, the processor shall assign an explanatory message to the specified variable as if by intrinsic assignment." [37:4] Before "}" add 'After para 3, add a new para: "The effect of a STAT= or an ERRMSG= specifier in a CRITICAL statement is explained in 8.5.7."' [38:40] Before "}" add "the following paragraphs, then add the final paragraph of 6.3 CRITICAL construct of this Technical Specification." ______________________________________________ Van Snyder "No,: for the reasons in part 1 of the attachment. But for those, I would vote "Yes, but I recommend changes in parts 2 and 3 of the attachment." -------------- next part -------------- Comments on N2048. Clause 9 not checked in detail. 1. Technical -- Mandatory ========================= These must be addressed for me to vote yes. ------------------------------------------------------------------------ As Malcolm pointed out during the previous ballot, use of the term "innermost" at [5:23 3.5.1] and [9:10 5.1] is nonsense. If you don't like Malcolm's words from the previous ballot, develop a term equivalent to the term "dynamically enclosed" in the Ada standard. ------------------------------------------------------------------------ Discussion of the CRITICAL statement is wrong. [16:5-7] Replace 6.3p2 with "If the processor detects that an image has failed during execution of a critical construct, the construct is regarded by other images as complete. "When an image executes a CRITICAL statement and the processor has detected that the previous image that entered the construct failed without completing execution of the construct, if the statement has a STAT= specifier the specified variable becomes defined with the value STAT_FAILED_IMAGE from the intrinsic module ISO_FORTRAN_ENV; if the statement has an ERRMSG= specifier the specified variable is assigned an explanatory message, as if by intrinsic assignment. If the previous image completed execution of the construct, the variable specified in the STAT= specifier becomes defined with the value zero, and the value of the variable specified in the ERRMSG= specifier is not changed." Edits to 8.5.7 are necessary as well. Discussion of the STAT= and ERRMSG= specifiers in the CRITICAL statement should refer to 8.1.5. ------------------------------------------------------------------------ There is no definition of "equal" for type logical. 8.4.3 needs either to define it, or use "equivalent". ------------------------------------------------------------------------ An image index assigned by the processor needs to be required to be unique within the team. [12:15] After "positive" insert ", unique within the team," 2. Technical Preferences ======================== ------------------------------------------------------------------------ There is no compelling reason that the and entities cannot come in any order. [9:33-34 R502] R502 <> CHANGE TEAM ( \smudge \smudge ) R502x <> <> [10:10+ C504+] C504a (R501) No specifier shall appear more than once in . ------------------------------------------------------------------------ There is no compelling reason that named specifiers cannot come in any order. And why is ERRMSG= not allowed? [11:4-5 R624] R624 <> \smudge \smudge [, ] R624x <> <> [11:8+ C509+] C509a (R624) TEAM_ID and TEAM shall not both appear. C509b (R624) No specifier shall appear more than once in . ------------------------------------------------------------------------ NOTE 6.2 illustrates why standard input should be available on all images. Either the program can decide which image gets to read it, and never try to read it until that image fails and a different one is chosen, or if several images want to read it, they can do it in critical sections. ------------------------------------------------------------------------ There is no apparent reason why the STAT argument of an atomic or collective procedure should have at least four decimal digits. The only remote clue is the "processor dependent value" described in 8.2p4 and 8.3p5. Statement specifiers to which a processor-dependent value might be assigned, for example in an ALLOCATE statement, do not require at least four digits. Equally mysterious is why the LENGTH and STATUS arguments to the GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE intrinsic subroutines, and the CMDSTAT argument to the EXECUTE_COMMAND_LINE intrinsic subroutine, require at least four digits, but those are not the topic of N2048. The VALUES argument to the DATE_AND_TIME intrinsic subroutine makes sense because the year is assigned to the first element. ------------------------------------------------------------------------ There is no apparent reason why the OPERATOR function passed to CO_REDUCE is not allowed to have optional arguments. There is no apparent reason why the OPERATOR function passed to CO_REDUCE is not allowed to have polymorphic arguments or result. Replace the first two sentences [26:10-11] with "shall be a pure function with explicit interface and at least two scalar, nonallocatable, nonpointer arguments of the same declared and dynamic type and type parameters as A. If it has more than two arguments, all arguments after the second argument shall be optional. Its result shall have the same declared and dynamic type and type parameters as A." At [26:12], delete "The arguments and result shall not be polymorphic." ------------------------------------------------------------------------ EVENT_QUERY should be a type-bound function, not an intrinsic function. 3. Editorial ============ "C509x (R624) [13:8] If this is not required to be the same SYNC TEAM statement, replace "executed a" with "executed any". Otherwise, replace "executed a" with "executed the same". [15:4] Replace the semicolon with a comma. [15:18] Part of the sentence is passive voice and part is active voice. Replace "Execution of" with "Executing". [16:22] After "STAT_UNLOCKED" insert "in that module". [17:13] Insert "of" before "type". [18:25+9 NOTE7.5:2] Specifying "Event variables of EVENT TYPE" implies that there are event variables of other types, to which the note does not apply. Remove "of type EVENT TYPE" because [17:8] defines an event variable to be a variable of EVENT TYPE. [24:38-39 8.4.11] Delete "It shall ... current team." because it cannot be otherwise. See 8.3p1. [25:22-23 8.4.12] Delete "It shall ... current team." because it cannot be otherwise. See 8.3p1. [26:3-4 8.4.13] Delete "It shall ... current team." because it cannot be otherwise. See 8.3p1. [26:37-38 8.4.14] Delete "It shall ... current team." because it cannot be otherwise. See 8.3p1. [28:5 8.4.16] Move the first sentence "If TEAM ... current team" to the description of the TEAM argument. It has nothing to do with the result value. [29:12 8.4.18] Move the first sentence "If TEAM ... current team" to the description of the TEAM argument. It has nothing to do with the result value. [29:29 8.4.19] Move the first sentence "If TEAM ... current team" to the description of the TEAM argument. It has nothing to do with the result value. [30:5 8.4.20] Move the first sentence "If TEAM ... current team" to the description of the TEAM argument. It has nothing to do with the result value. [44:8-20] Edits to Annex A are needed for the case of a processor-dependent value being assigned to a STAT argument in a reference to an atomic or collective intrinsic procedure.