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:<div>
<br></div><div><i>"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."</i><br><br>
If you think something is underspecified or improperly specified, please give an example.<br><br><div class="gmail_quote">On Sun, Sep 23, 2012 at 4:30 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Obviously the read fence is the relevant issue here. Your example is now the following (cf. MPI-3 Example 11.9)</div>
<div><br></div><div><div>origin:</div>
<div>MPI_Win_create</div><div>MPI_Win_lock</div><div>MPI_Put</div><div>MPI_Win_unlock</div><div>notify(side_channel) // e.g., global variable in shared memory, memory-mapped serial line, file system</div><div><br></div><div>

target:</div><div>double buffer[10] = {0};</div><div>MPI_Win_create(buffer,....)</div><div>wait(side_channel) // e.g., spin</div><div>x = buffer[0]</div></div><div></div></blockquote></div><br></div>