Pavan Balaji <[email protected]> writes:

FLUSH will guarantee that the data is present in the remote public memory. And UNIFIED states that public memory == private memory. So, the user can read it directly without any additional MPI calls.

That's the broken part.

Modulo a memory barrier, depending on the architecture. Should the statement be strengthened so that the user must _either_ call MPI_Win_sync (with implementations expected to provide a fast path for UNIFIED) or perform any architecture-specific synchronization, which of course may piggyback on other synchronization, thus being lighter weight. Alternatively, add a new MPI function that does not take an MPI_Win argument and just performs a suitable memory fence. This would make it explicit that UNIFIED does not need per-window synchronization. Should MPI be in the business of providing basic memory fences, or is the user expected to get it from their language (C11/C++11), their own inline assembly, or third-party libraries like ConcurrencyKit? As it is now, the user has to put in a fair bit of effort to write portable code with UNIFIED.