PAGE:LINE EDIT ------------------------------------------------------------------------------- 1:36 "(remote -fetch- +read+ and update)" 1:38 "accumulate" operations is problematic since compare_and_swap is does not take an op. So, "same op is non-conflicting" statements later are problematic. I prefer "atomic" so it is clearer later when we refer "accumulate" operations as a group. 1:42 "different memory models +: unified and separate+" 3:47-42 accumulate_ops statement is problematic since this excludes compare and swap. 5:XX Ignore, no edits here. 6:XX Should we include the linked list example I put together earlier as a dynamic windows example? If so, we should put it in an examples section at the end. 6:29 No new paragraph here. 7:XX Can we change the memory model of a window by attaching memory to it? It seems like we can, so this should be specified here - you will need to re-check after each attach to see if it changed. 8:19 "Memory becomes detached +but is not automatically freed+ when ..." 9:XX Add an MPI_WIN_MODEL as a window attribute. We've removed datatype and op from the call, so now it fits as a window attribute and shouldn't need its own API. 10:37 "The outcome of conflicting +concurrent+ accesses ..." 10:XX It's not clear in here when the undefined-ness is on the region of overlap and when it's on the whole window. This needs to be clearly defined for the combination of communication operations vs load/store and unified vs separate models. 14:4 "Examples" should be more specific since not all examples are assembled here, primarily put/get. 15:27 MPI_Win_fence has not been introduced yet. Might be good to move these examples to the end of the document. 15:XX Example 11.2 is a simplified version of 11.1, it would be preferable to have this one come first since it will help build up to the full example. 16:XX I would prefer 11.3.4 to be called "Atomic Operations" since not all functions in this chapter are accumulate functions. 20:7 "MPI_GET is -a special case of- +similar to+ MPI_GET_ACCUMULATE..." Get doesn't have the same semantics, so it's not a special case of get_acc 21:35-36 This should be a list of MPI types, not "C Integer, ..." 22:40 Add a section reference for MPI_PUT 23:30 Add a section reference for MPI_GET 23:33 Add to the last paragraph: "If the origin buffer is in an MPI window, then the data will be available in the window's private copy (see Section 11.4)." 24:32 Add a section reference for MPI_Accumulate 25:39 Add a section reference for MPI_Get_accumulate 26:16 Caption: "... MIN_WIN_SEPARATE memory model +for two overlapping windows.+" 26:38 "MPI sends" and "MPI receives" should be broader to include all MPI communication operations (including get/put). 26:44 Remove blank line. 26:48 Replace the last sentence with: "These stronger semantics allow some synchronization calls to be omitted, enabling the programmer to take advantage of hardware capabilities that allow the public and private copies of the window to be the same." 27:2 Locks and flushes haven't been introduced yet. Refer to Section 11.5. 27:XX Merge MPI_Win_query with attributes. 27:29 "RMA operation and datatype" have been removed from the call 31:35 Replace sentence two in the rationale with: "Many such synchronization algorithms are possible and suit different algorithmic purposes. MPI provides the primitives (e.g. MPI_COMPARE_AND_SWAP, MPI_GET_ACCUMULATE, MPI_SEND/MPI_RECV, etc...) needed to implement these higher-level synchronization operations." 39:24 "Flush completes locally, meaning that the operation must complete without..." 39:38 Add sentence: "This operation also completes locally." 40:25 Add sentence: "This operation has no effect for windows in the unified model." 45:18 Remove "because of resource exhaustion". There are other reasons why attach could fail. 45:25 This is new text, could you add back the original text in green? 46:1 "the operation is +also+ completed at..." 46:7 "In the RMA unified memory model the public and private windows are the same. Thus, an update of a location in the private copy of the window becomes visible when the RMA operation completes at the target without any additional RMA calls. 46:15 "In the RMA unified memory model the public and private windows are the same. Thus, an update by a put or accumulate call to a public copy of the window becomes visible in process memory without and additional RMA calls." 47:5 "do not have a defined behavior" -> "produce undefined results on the region of overlap." 48:1 Not sure I like this. It's better use use send/recv for notification. 49:31 "process B -is- +are+" 50:7 Change MPI_Win_lock_all to MPI_Win_lock(SHARED) and corresponding unlock. 54:XX Add request-based operation examples and linked list example. Separate the examples from the semantics demonstrators and put into a section at the end.