[Mpi3-rma] MPI-3 UNIFIED model clarification

Jed Brown jedbrown at mcs.anl.gov
Mon Jul 29 15:58:01 CDT 2013


Pavan Balaji <balaji at mcs.anl.gov> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130730/80eb68eb/attachment-0001.pgp>


More information about the mpiwg-rma mailing list