MPI-3共享内存操作：何时需额外调用MPI_Win_sync()及相关平台疑问

Let me break this down based on MPI-3 specifications and real-world development experience:

1. When do you need an extra call to MPI_Win_sync() with MPI-3 shared memory operations? #

MPI_Win_sync() exists to sync your local process's memory view with the MPI shared memory window — it ensures local store operations become visible to other processes, or that local loads can see the latest updates from other peers. You'll need it in these key scenarios:

• When using passive RMA (direct memory access): If your process writes directly to the shared memory window (not via MPI RMA functions like MPI_Put() or MPI_Accumulate()), call MPI_Win_sync() after writing to flush those changes out of your local cache and make them visible to others. Conversely, if you're about to read directly from shared memory that other processes might have modified, call MPI_Win_sync() first to refresh your local cache and get the latest values.
• When using MPI_MODE_NOCHECK window mode: This mode skips some consistency checks for performance gains. Since the target side is assumed to start accessing immediately, you may need MPI_Win_sync() to bridge gaps between MPI synchronization primitives (like barriers) and hardware-level cache consistency.
• After cross-process synchronization primitives (in edge cases): As your second question hints, on certain platforms, even after MPI_Barrier(), you might need MPI_Win_sync() to ensure full memory consistency for shared memory access.

2. Which platforms require an extra MPI_Win_sync() after MPI_Barrier? #

This boils down to hardware memory models and how the MPI implementation interacts with the system's cache coherence protocols. Here's what you need to know:

• Weak memory consistency architectures: Platforms like PowerPC, non-server ARM (e.g., embedded or some ARM-based clusters), and IBM Blue Gene/Q fall into this category. These systems don't guarantee that cache updates are automatically propagated across cores/processes after a barrier. The MPI_Barrier() ensures process synchronization, but not necessarily full cache flushing — hence the need for an explicit MPI_Win_sync() to make shared memory changes visible.
• Some edge cases on x86/x86_64: While x86 has strong cache coherence by default, certain MPI configurations (e.g., older Open MPI versions or specialized Intel MPI setups) might still recommend MPI_Win_sync() after barriers in specific scenarios, though this is far less common.
• Always check your MPI implementation docs: Specific requirements can vary by vendor. For example, Intel's documentation calls out this need for certain weak-consistency platforms, as noted in your source material.

内容的提问来源于stack exchange，提问作者Patrick Sanan