To: J3 08-290r1 From: Bill Long Subject: Replies to coarray and volatile issues Date: 2008 November 18 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.11+ 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. A Note 2.18+ 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 lead 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 in the statement that performs them (except when explicitly stated otherwise); - executed statements are totally ordered within a segment; - 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 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, the processor shall 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, on image P (1) a variable X on image Q is defined, referenced, becomes undefined, or has its allocation status, allocation 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, allocation 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, 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 of the initial part on image P to precede the completion part on image Q. The mechanisms available for creating such a dependency may be processor-dependent." [309:C1279+] In "12.7 Pure procedures", after the sixth constraint, add a new constraint: "C1279a The value, allocation status, pointer association status, dynamic type, type parameters, or array bounds of a variable with the VOLATILE attribute shall not be referenced or defined in a pure subprogram."