09-186 To: J3 From: Van Snyder Subject: SYNC problems, especially SYNC MEMORY Date: 2009 April 10 Reference: 09-007r1 1. Discussion Subclause 8.5.5 of 09-007r1 is composed mostly of bubble gum, masking tape, and paper clips, but slightly less so than 5.3.19. Perhaps this is intentional and necessary, but it is nonetheless needlessly confusing. 8.5.1 and 8.5.5 need to say clearly that unlike other image control statements, a SYNC MEMORY statement does not cause automatic synchronization at the segment boundary it creates. The term SYNC MEMORY is an unfortunate and misleading misnomer, but it's probably too late to change it to something less confusing, say SEGMENT BOUNDARY. 8.5.5 needs to say more clearly what it means by "initiate a cooperative synchronization," and not elsewhere use an even more confusing description ("some form of cooperation with other images for the purpose of ordering execution between images") for it. The adjective "cooperative" appears in only three places within two paragraphs in 8.5.5, and in a line in Annex A that refers to 8.5.5. Is "uncooperative synchronization" even possible? The appearance of "cooperative" gives the impression that it might be possible. One has to deduce from the explanations of the relationship between allocation and deallocation, including implicit deallocation, and other images, that they in fact have the same effect as SYNC ALL. It would be simpler just to say so. In all but one place (which ought to be in the discussion of SYNC ALL) it should be in a note so as not to say normative things in more than one place. There is nothing in the discussion of the or the STOP statement that says they have the effect of the SYNC ALL statement. Rather than waiting until one reads (or tries to read) 8.5.5 to discover that all segment boundaries impose an ordering, within a single image, of actions affecting data on other images, this effect should be in "8.5.2 Segments" instead of hidden in 8.5.5 ("All other image control statements include the effect of executing a SYNC MEMORY statement"). Worse yet, it seems that **executing** a SYNC MEMORY statement doesn't actually do anything, so referring to the effect of executing it would be a mistake. 2. Edits [32:7+ 2.3.3p2+]-------------------------------------------------------- Editor: Insert the following note: "NOTE 8.26a Execution of an statement includes the effect of execution of a SYNC ALL statement (8.5.3). An image can discard all of its data objects that are not coarrays, and close all of its files other than those identified by OUTPUT_UNIT and ERROR_UNIT, before this effect of execution of a SYNC ALL statement is complete." Yes, a note, because the normative text that says this is put into 8.5.3 by edits below for [191:10+ 8.5.3p2+]. [130:12 6.7.1.2p3]------------------------------------------------------ Editor: Replace "each" by "every". [130:15-17 6.7.1.2p4]--------------------------------------------------- Editor: Replace the unnecessarily wordy paragraph and duplicative with the following note, which is more precise, avoids normative duplication, and refers to the proper discussion: "NOTE 6.19a Execution of an ALLOCATE statement that allocates one or more coarrays includes the effect of execution of a SYNC ALL statement (8.5.3)." Yes, a note, because the normative text that says this is put into 8.5.3 by edits below for [191:10+ 8.5.3p2+]. [133:16-22 6.7.3.2p11-12]----------------------------------------------- Editor: Delete the unnecessarily wordy and duplicative paragraphs. A note is inserted at a better place. [133:24+ 6.7.3.2p13+]--------------------------------------------------- Editor: insert the following note, which is more precise than 6.7.3.2p11-12, avoids duplication, and refers to the proper discussion: "NOTE 6.24a Execution of a DEALLOCATE statement that deallocates one or more coarrays, or of any other statement that causes implicit deallocation of one or more coarrays, includes the effect of execution of a SYNC ALL statement (8.5.3)." Yes, a note, because the normative text that says this is put into 8.5.3 by edits below for [191:10+ 8.5.3p2+]. [189:9+ 8.4p1+]--------------------------------------------------------- Editor: Insert the following note: "NOTE 8.26a Execution of a STOP statement includes the effect of execution of a SYNC ALL statement (8.5.3). An image can discard all of its data objects that are not coarrays, and close all of its files other than those identified by OUTPUT_UNIT and ERROR_UNIT, before this effect of execution of a SYNC ALL statement is complete." Yes, a note, because the normative text that says this is put into 8.5.3 by edits below for [191:10+ 8.5.3p2+]. [189:17 8.5.1p1]-------------------------------------------------------- Editor: Delete "as". [189:18 8.5.1p2]-------------------------------------------------------- The first sentence is untrue, since SYNC MEMORY does not on its own affect the execution ordering between images. Other than SYNC MEMORY, it's not the statement but execution of it that affects execution order between images. The fact that they divide the execution sequence on each image into segments should be mentioned here instead of in 8.5.5. Editor: After "An image control statement" insert "divides the execution sequence on each image into segments (8.5.2). Execution of an image control statement other than a SYNC MEMORY statement". [189:26 8.5.1p2]-------------------------------------------------------- An END or RETURN statement doesn't "involve" implicit deallocation. Execution of it does "cause" or "result in" implicit deallocation. Editor: Replace "that involves an" by "if execution of it could cause" or "if execution of it could result in" (see [189:27]). [189:27 8.5.1p2]-------------------------------------------------------- A statement that completes execution of a block doesn't result in implicit deallocation. Execution of it does result in implicit deallocation. Editor: Replace "and" by "if execution of it could" [190:2 8.5.2p2]--------------------------------------------------------- Editor: Replace ", or" by "other than SYNC MEMORY, or by". {What does "execution of user-defined ordering" mean?} [190:22 8.5.2p3]-------------------------------------------------------- The effective argument is necessarily a coarray, else another image couldn't fiddle it, but it wouldn't hurt to say so. It is impossible for the effective argument to be allocated or deallocated by another image because allocation and deallocation are image controls, so it isn't necessary to say so here. Editor: After "dummy argument" insert "associated with a coarray effective argument". [190:7+ 8.5.2p1+]------------------------------------------------------- 8.5.5p2 belongs here, expressed in terms of segment boundaries instead of the SYNC MEMORY statement. It should be a requirement, not an observation. Editor: Add a paragraph: "If o execution of a statement in segment P_i references or defines a coindexed object X on image Q, causes it to become undefined, or changes or inquires about its allocation status, pointer association status, array bounds, dynamic type, or type parameters, and o execution of a statement in segment P_{i+1} references or defines a coindexed object Y on image Q, causes it to become undefined, or changes or inquires about its allocation status, pointer association status, array bounds, dynamic type, or type parameters, then the action on image P regarding X on image Q shall precede the action in image P regarding Y on image Q, even if X and Y are the same object." This has to be about coindexed objects, not just any old variable, else it doesn't make sense. Do we need to mention "pointer association status" here, since fiddling the pointer association status of a coindexed object is verboten? If we actually need to mention allocation status, array bounds, dynamic type, and type parameters here, then cobounds should be in the list as well, since allocation could affect them. Given, however, that allocation and deallocation are image controls, this seems overly complicated: the allocation status, array bounds, dynamic type, and type parameters of a coindexed object can only be changed or become undefined by allocation or deallocation. It ought to be good enough to say "If o execution of a statement in segment P_i references or defines a coindexed object X on image Q, or causes it to become undefined, and o execution of a statement in segment P_{i+1} references or defines a coindexed object Y on image Q, or causes it to become undefined, then the action on image P regarding X on image Q shall precede the action in image P regarding Y on image Q, even if X and Y are the same object." Isn't this transitive? Shouldn't it be something along the lines of "In a sequence of segments P_i, P_{i+1} ... P_{i+n}, if o execution of a statement in segment P_j references or defines a coindexed object X on image Q, or causes it to become undefined, and o execution of a statement in segment P_k references or defines a coindexed object Y on image Q, or causes it to become undefined, and $i \leq j < k \leq i+n$, then the action on image P regarding X on image Q shall precede the action on image P regarding Y on image Q, even if X and Y are the same object." [191:10+ 8.5.3p2+]------------------------------------------------------ Editor: Add a paragraph: "Execution of o an ALLOCATE or DEALLOCATE statement that allocates or deallocates a coarray, o an END or RETURN statement that causes implicit deallocation of a coarray, o any statement that completes execution of a block (8.1.2.2) and results in implicit deallocation of a coarray, o a STOP statement, or o the END statement of the main program includes the effect of execution of a SYNC ALL statement." Maybe replace "causes" in the second item by "results in" for foolishly held consistency. [192:5-6 8.5.5p1]------------------------------------------------------- Needlessly verbose ("provides a means of dividing"), duplicates the specification in 8.5.2 that SYNC MEMORY is a segment boundary anyway, and needs to say that SYNC MEMORY doesn't cause synchronization. It's the SYNC MEMORY statement, not the execution of it, that divides segments. How can a segment be divided into two segments? SYNC MEMORY is already defined to be a segment boundary so the two segments are just sitting there anyway. It's just too weird to say "divides what would otherwise be a single segment into two segments." Furthermore, all image control statements do this so it would belong in 8.5.1 anyway. It's no longer necessary to say "All other image control statements include the effect of a SYNC MEMORY statement" because that's now explicit in 8.5.2 as a result of the edit above for [190:7+ 8.5.2p1+]. Editor: Replace paragraph 8.5.5p1 by "<<8.5.5.1 General>> [192:7+ 8.5.5p1+]------------------------------------------------------- Editor: Insert the following note (not normative because everything here is said elsewhere): "NOTE 8.37a Because it is a segment boundary, the SYNC MEMORY statement enforces inter-segment ordering, within a single image's execution sequence, of actions affecting other images. Unlike other image control statements, the SYNC MEMORY statement does not cause synchronization between images." [192:8-193:7]----------------------------------------------------------- This is about segment boundaries in general, and has nothing to do with actual execution of a SYNC MEMORY statement, successful or otherwise. It belongs in 8.5.2. Edits above for [190:7+] do this. Editor: Delete the paragraph. [193:7+ 8.5.5p2+]------------------------------------------------------- The remainder of 8.5.5 is about user-defined segment ordering, not specifically about SYNC MEMORY. The only reference to 8.5.5 [at 190:8 8.5.2p2] concerns user-defined ordering. Editor: Insert a new subclause division: "<<8.5.5.2 User-defined segment ordering>>" and change the reference at [190:8 8.5.2p2] to refer to it. Maybe this should be a third-level subclause after 8.5.6. The astute observer will notice at this point that 8.5.5.1 now consists only of a syntax rule and a note. [193:8 8.5.5p3]--------------------------------------------------------- Make it clearer we're not talking about image control statements. Editor: Replace the line that introduces the list by the following: "In addition to segment ordering caused by execution of an image control statement other than SYNC MEMORY, segment P_i on image P is caused to precede segment Q_j on image Q when" [193:9,12 8.5.5p3]------------------------------------------------------ The term "image control statement" here is almost certainly intended to be "SYNC MEMORY statement", since all the other image control statements cause synchronization on their own. Editor: Replace "an image control" by "a SYNC MEMORY" in both places. [193:10 8.5.5p3]-------------------------------------------------------- Editor: Delete "a cooperative". [193:11 8.5.5p3]-------------------------------------------------------- Editor: Delete "the cooperative". [193:13-16 8.5.5p4]----------------------------------------------------- This isn't a requirement on the processor or the program, any more than a Newton method returning the zero of a polynomial would be. Rather, it is an explanation of one method by which the requirements of 8.5.2p3 might be met. NOTE 8.39 appears to exploit a synchronization method that is not processor dependent. "The mechanisms ... dependent" should not be normative. Editor: Replace paragraph 8.5.5p4 by the following note: "NOTE 8.37b In order to enforce ordering between segments P_i and Q_j, synchronization between images P and Q must cause execution of the statements that initiate the synchronization on image P in segment P_i to precede execution of the statements on image Q in segment Q_j that complete the synchronization. A processor-dependent mechanism might be used to cause such a dependency." Yes, "must" is the correct word here, since it is an unavoidable consequence of a requirement, not a requirement. [193:17-19 8.5.5p5]----------------------------------------------------- Except for the first sentence, which edits above for [192:5-6] have moved into 8.5.5p1, this paragraph should be a note because it repeats 8.5.2p2. It should say "synchronization" instead of beating around the bush in the hope the reader will nonetheless get the idea that "some form of cooperation with other images for the purpose of ordering execution between images" is the same concept. Paragraph 8.5.2p2 is nearby, so paragraph 8.5.5p5 could just be deleted. Editor: Either delete paragraph 8.5.5p5 or replace it by "NOTE 8.37c Execution of an image control statement other than SYNC MEMORY causes synchronization with other images, and therefore imposes an inter-image ordering (8.5.2) on segments that immediately precede and succeed that statement in the execution sequence on each image." [194:1- 8.5.5 NOTE 8.40+]----------------------------------------------- Editor: Insert the following note: "NOTE 8.40a Synchronization by means other than image control statements is almost always implemented incorrectly. Do not pay any attention to this subclause, or use any of the methods described herein, unless it is absolutely necessary to do so. Double and triple check the program. Do not use it for anything important unless you have exceedingly good attorneys and insurance." Maybe put it at [197:7+], immediately after the new 8.5.5.2 subheading. [464:21 A.2]------------------------------------------------------------ Editor: Delete the processor dependency notice concerning 8.5.5 (see the edit for [193:13-16 8.5.5p4]) unless we mention processor dependencies that appear in notes in this Annex, in which case it should be replaced by "o some methods for inter-image synchronization other than by using image control statements might be processor dependent (8.5.5.2);" 3. Comments without edits Maybe the appropriate subgroup will find it useful to supply edits to address some of the concerns mentioned here. 8.5.5p3 and NOTE 8.39 are inconsistent. NOTE 8.39 claims that the CALL ATOMIC_DEFINE is in segment P_i, but then I don't see anything AFTER the next segment boundary, i.e. within segment P_{i+1}, that might cause synchronization. The "Preceding segment" comment should be "Segment P_i" and the "segment P_i" comment should be "segment P_{i+1}". The "segment Q_j" comment should be "segment Q_{j-1}" since the shortly-to-follow SYNC MEMORY statement is presumably the one that begins segment Q_j. Futher on in the note, the references to P_i and Q_j are also inconsistent with 8.5.5p3. The whole IF construct in NOTE 8.39 should be enclosed within IF ( P /= Q ) THEN... ENDIF, or at least there should be a comment that this code doesn't make sense and ought not to be executed if P == Q. Is it possible for an error condition to occur during execution of a SYNC MEMORY statement? If not, why bother with [([])]? I suspect that SYNC MEMORY doesn't do more during execution than a CONTINUE statement that doesn't end a DO construct, i.e., nothing. SYNC MEMORY puts constraints on the compiler's register allocation strategy but doesn't actually do anything at run time that's observable in the sense of 2.5.3. If [([])] is deleted from SYNC MEMORY, delete mention of SYNC MEMORY from 8.5.7 as well. Other than evaluation of expressions within an image control statement, is execution of one within either the image that precedes it or the image that succeeds it? I think not, since the terms "ends segment" and "begins segment" are both applied to image control statements. Perhaps 8.5.2p1 needs another sentence at the end, something like "Otherwise, execution of an image control statement is not part of either the segment that precedes it or the segment that succeeds it." I don't think we want to say it's in both segments, or the segment boundary is actually at some ill-defined (worse yet undefined) place within the image-control statement. OTOH, 8.5.2 doesn't actually say that every executable statement is executed within some segment, so maybe there's no problem here.