MPI-2.2 Example 11.15 is a more direct example of the incorrectness of the hypothetical code below. Since MPI-2 semantics are like MPI-3 MPI_WIN_SEPARATE, I assumed you were referring to MPI-3 with MPI_WIN_UNIFIED. Even with MPI_WIN_UNIFIED, there is no portable way for a target of a passive-mode RMA operation to get the result without an explicit call (such as MPI_Win_lock, MPI_Win_sync, etc), see MPI-3 Example 11.9 and 11.12. The standard points out that lower-overhead non-portable solutions may exist: *"Compiler and hardware specific notations could ensure the load occurs after the data is updated, or explicit one-sided synchronization calls can be used to ensure the proper result."* If you think something is underspecified or improperly specified, please give an example. On Sun, Sep 23, 2012 at 4:30 PM, Jed Brown <[email protected]> wrote:
Obviously the read fence is the relevant issue here. Your example is now the following (cf. MPI-3 Example 11.9)
origin: MPI_Win_create MPI_Win_lock MPI_Put MPI_Win_unlock notify(side_channel) // e.g., global variable in shared memory, memory-mapped serial line, file system
target: double buffer[10] = {0}; MPI_Win_create(buffer,....) wait(side_channel) // e.g., spin x = buffer[0]