[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