To: J3 08-290r2 From: Bill Long Subject: Replies to coarray and volatile issues Date: 2008 November 19 References: N1723/08-007r2,N1744,N1745,N1748,N1749,N1751,08-284 ----------- Discussion: WG5 papers N1744, N1745, N1748, N1749, and N1751 contain comments and suggestions regarding, primarily, the coarray feature in the Fortran 2008 draft. This paper collects together edits motivated by those papers, and a summary discussion of each corresponding issue. Meaning of Sequence in Time: The Execution subclause (2.4.5) uses the concept of "a sequence in time". Some added explanation of what this actually means would help clarify the standard. A Note 2.11a is provided below for this. Additional discussion, and original wording for the Note, is in N1748. Local coindexed references: The Coarray subclause (2.5.7) says that a coarray may be referenced on its own image without specifying cosubscripts. The implication is that the references with and without the cosubscripts are equivalent for cases where either is allowed. Note 2.18a is provided below to say this. Additional discussion, and original wording for the Note, is in N1748. Volatile spec: The VOLATILE attribute subclause (5.3.19) currently permits an object to have the volatile attribute in some scoping units and not others. N1749 points out that, for some hardware and data size combinations, volatile definitions or references might require the use of particular machine instructions to ensure the integrity of the values. If the processor is unable to determine whether an object is volatile, such restrictions might affect all variables, having a negative impact on performance. While this has nominally been an issue before the introduction of coarrays, the addition of coarrays provides an opportunity to resolve this problem at least for coarrays. Edits are provided below to require that, for the case of a coarray, it and any associated object shall have the volatile object in all scoping units if it is volatile in any. This resolves the ambiguity that led to the problems noted above. A corresponding change for variables that are not coarrays is not included to avoid a backward incompatibility with the current standard. Meaning of sync memory and user-defined synchronization: Subclause 8.5.4 on the SYNC MEMORY statement and its use in enabling user-defined synchronization lacks specifics on what the statement actually does and how user-defined synchronization works in general, rather relying on examples in Notes. Edits are provided below for added normative text to provide a better description of these concepts. Additional discussion is in N1748. Volatile and Pure procedures: Example 3.1 from N1745 points out that a volatile coarray referenced in a PURE procedure can lead to unexpected results. This is actually a problem for volatile variables in general, though the coarray example provides a simple illustration. Edits are provided below to prohibit referencing or defining a volatile variable in a PURE procedure. Paper J3/08-284 submits in Interp for Fortran 2003 on this same issue. Edits to identify a backward incompatibility will not be needed if the edits proposed in J3/08-284 are incorporated into Fortran 2003. Assuring program progress: In an execution environment where multiple images share a single processor core, and multiple images that are relatively unordered are virtually executing, it is not explicitly stated in the standard that the processor is expected to provide cycles to all the images in some fair way. If certain of the images never get processor time, the program overall might deadlock. A Note is supplied to say that execution of all images is expected of the processor. --------------------- EDITS to J3/08-007r2: [32:2.4.5p3+] In "2.4.5 Execution sequence", add a new Note after paragraph 3: "NOTE 2.11a The above rules, taken together, define what is meant by 'a sequence in time' (2.4.1). Execution of a conforming program is as if: - actions take place during execution of the statement that performs them (except when explicitly stated otherwise); - the segments executed by a single image are totally ordered; - and the segments executed by separate images are partially ordered by image control statements (8.5.1). End NOTE" [36:2.5.7Note 2.18+] At the end of "2.5.7 Coarray", add a new Note: "NOTE 2.18a Except in contexts where coindexed objects are disallowed, accessing a coarray on its own image by using a set of cosubscripts that specify the image has the same effect as accessing it without cosubscripts. In particular, the segment ordering rules (8.5.1) apply whether or not cosubscripts are used to access the coarray. End NOTE" [100:5.3.19p2] In "5.3.19 VOLATILE attribute", in the first sentence of paragraph 2, replace "An object may have" with "An object that is not a coarray may have" After sentence 1, add a new sentence: "An object that is associated with a coarray shall have the VOLATILE attribute if and only if the coarray has the VOLATILE attribute." [188:8.5.1p6-] In "8.5.1 Image control statements", between Note 8.29 and paragraph 6, add a new Note: "NOTE 8.29a If the segments S_1, S_2, ..., S_k on the distinct images P_1, P_2, ..., P_k are all unordered with respect to each other, it is expected that the processor will ensure that each of these images is provided with an equitable share of resources for executing its segment. End NOTE" [190:p2-] In "8.5.4 SYNC MEMORY statement", after R862, add new paragraphs: "If, by execution of statements on image P (1) a variable X on image Q is defined, referenced, becomes undefined, or has its allocation status, pointer association status, array bounds, dynamic type, or type parameters changed or inquired about by execution of a statement, (2) that statement precedes a successful execution of a SYNC MEMORY statement, and (3) a variable Y on image Q is defined, referenced, becomes undefined, or has its allocation status, pointer association status, array bounds, dynamic type, or type parameters changed or inquired about by execution of a statement that succeeds execution of that SYNC MEMORY statement, then the actions affecting X on image Q precede the actions affecting Y on image Q. User-defined ordering of segment Pi on image P to precede segment Qj on image Q takes the following form: (1) Image P executes an image control statement that ends segment Pi, and then executes statements that initiate a cooperative synchronization between images P and Q, and (2) Image Q executes statements that complete the cooperative synchronization between images P and Q and then executes an image control statement that starts segment Qj. Execution of the cooperative synchronization between images P and Q shall include a dependency that forces execution on image P of the statements that initiate the synchronization to precede the execution on image Q of the statements that complete the synchronization. The mechanisms available for creating such a dependency are processor-dependent." [309:C1279+] In "12.7 Pure procedures", after the sixth constraint, add a new constraint: "C1279a A designator for a variable with the VOLATILE attribute shall not appear in a pure subprogram" [Note to Editor: If we decide to similarly modify Fortran 2003, the edit for C1279a should match text for the reply to the interp on the same issue in 08-284.] [460:Annex A] In Annex A, after the entry "the manner in which the stop code ..." add a new entry: "the mechanisms available for creating dependencies for user-defined synchronizations (8.5.4);"