To: J3 J3/13-342r2 From: Bill Long & John Reid Subject: Comments on EVENTS Date: 2013 October 18 References: N1983, N1989, 13-301 Discussion - Responses with edits --------------------------------- {Dan 4}: In [13:9] change "includes" to "references" to avoid constraining the implementation. Response: At [13:10-11] we say that the initial count value is zero. Vaguely implying that count is a component with default initialization. An edit is provided to avoid the implementation issue. {Van 12}: At [13:15] "in a" -> "in an". Response: Agreed. Edit included below. {Dan 5}: Add a statement that the order of event posts is processor-dependent. Response: See {Bill I6}. {Van 13}: At [13:24] Is the EVENT POST statement the only way to post an event? It would be neutral to say "Execution of an EVENT POST statement posts an event." Response: The current text needs improvement. This is covered by an edit to [13:29]. {Bill I6}: At [13:29+] In the new Atomic subroutines section we say that "How sequences of atomic actions in unordered segments interleave with each other is processor dependent." That text is copied from F2008. Should we have a similar statement about event posts, since they are similar to atomic operations? Response: Yes. Edits are provided. {Nick 10a}: 6.3 p13:29. The sentences referring to unsuccessful [posts] should be removed, as there are no defined conditions that can cause them to fail and still given them access to the event variable. Response: For consistency with the standard, we should be talking about "error conditions" rather than "unsuccessful posts". We do not spell out all possible error conditions, but an event post might detect that it was trying to post to a failed image and an event wait statement might detect that information sent from the posting image had become corrupted, of the operation failed because of a network timeout. An edit is provided. {Van 14}: At [13:31] Is the EVENT WAIT statement the only way to wait for an event? It would be neutral to say "Execution of an EVENT WAIT statement waits until an event is posted." Response: This is covered by the edit to [14:1-2]. {Van 15}: At [14:1-2] What is "success" for a wait? Is it waiting, or continuing without needing to wait, or what? Response: An edit is provided to reword these sentences. See also {Nick 10b} with further edits this paragraph. {Nick 10b}: 6.4 p14:2. The sentences referring to unsuccessful waits should be removed, as there are no defined conditions that can cause them to fail and still given them access to the event variable. Response: See response for {Nick 10a}. A similar edit is provided. {Nick 11}: 6.4 p14:3-7. At least two responses to N1967 pointed out that the definition of sequencing makes no sense, on the grounds that ordering between images is defined only by image control statements, and the order of these image control statements depends on the ordering between images! This is not a simple matter, and simple wording changes will not resolve it. As I commented there, the easiest solution to this is to change events from general semaphores into binary ones, and define an error return from EVENT POST if the event is already posted. If this is not done, some mathematically consistent definition of the ordering must be provided. As this appears to be beyond the state of the art in computer science, it may be hard to achieve. Response: An event variable exists on a single image and changes to it are essentially atomic. An edit is provided. Discussion - Responses only --------------------------- {Reinhold B.1}: Introduce split barrier facility. This is the topic of paper 13-301. {Nick 9}: 6.2 p13:15-18. To avoid the array copying problem, this also needs to exclude explicit-shape and assumed-size arrays containing event variables. Response: Copying cannot happen because an event variable is required to be a coarray. {Dan 9}: Clarify that the order of arrival of the effects of event posts and event waits is processor dependent. Response: For event posts, see {Dan 5}. For event waits, there is no "order of arrival" issue since event waits are always local and the count increments are not tagged. Edits to N1983 -------------- [13:7-8] {Ed} Change "All components have default initialization" to "Each component is fully default initialized". {Similar to edit in 13-335r3 for TEAM_TYPE.} [13:9] {Dan 4} Change "includes" to "has". [13:15] {Van 12} Change last "in a" to "in an". [13:29] {Van 13} Change "A successful post to an event variable increments its count." to "Successful execution of an EVENT POST statement increments the event variable's count.". [13:29] {Nick 10a} Change "An unsuccessful post does not change the count." to "If an error condition occurs during the execution of an EVENT POST statement, the count does not change." [13:29+] {Bill I6} Add paragraph: "How sequences of posts in unordered segments interleave with each other is processor dependent." [14:1-2] {Van 14, Nick 10b} replace entire para with "Execution of an EVENT WAIT statement causes the executing image to wait until the count of the event variable is positive or an error condition occurs. If no error condition occurs, the count of the event variable is decreased by 1.". [14:3] {Van m30} Change "During the execution" to "During execution". [14:4] {Nick 11} Before "If the count" add sentence: "The effect of each change is as if it occurred instantaneously, without any overlap with another change.". [14:4-5] {Van m31} Change "through" to "because of" twice. [31:29] {Bill I6} At the end of 8.9, adjust the end-of-line punctuation and add a new processor dependency: " how sequences of posts in unordered segments interleave with each other."