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 <jedbrown@mcs.anl.gov> 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]