[Mpi3-rma] MPI-3 UNIFIED model clarification

[Jim Dinan]

Hi Pavan,

I believe this is adequately specified on pg 436, line 37.  P1 will
*eventually* see the new value for "a" without any additional
synchronization operations, but neither the flush by P0 nor the Recv by P1
guarantee that P1 will see the new value immediately.

 ~Jim.


On Sat, Jul 27, 2013 at 1:08 PM, Pavan Balaji <balaji at mcs.anl.gov> wrote:

> Dear all,
>
> We had some discussion on the semantics of UNIFIED in the past, that
> we were hoping to have clarified in MPI-3.1 or the errata.  This email
> is to revive that discussion, so that we don't forget to address it.
>
> Specifically, the concern was that some members of the WG believed
> that in the UNIFIED model, data is usable by the remote process after
> a PUT without an additional WIN_SYNC, while some members believed that
> it is not.  Here's the example in question:
>
> P0:
> Win_lock_all
> Put(a, P1)
> Flush
> MPI_Send(P1)
>
> P1:
> Win_lock_all
> MPI_Recv(P0)
> read a
>
> The question was whether the above program was valid without a
> WIN_SYNC on P1 between the Recv(P0) and "read a".  If we want this to
> be valid in the UNIFIED model, only x86-like architectures can provide
> UNIFIED efficiently.  Other architectures, such as PPC or ARM, that
> require an additional read barrier on P1 will not be able to provide
> UNIFIED even if they are cache-coherent, unless they add a memory barrier
> in every other MPI call (e.g., MPI_Recv in this case).
>
> One possible solution we discussed was to clarify that this is not
> allowed in UNIFIED, but provide a third memory model called
> UBER_SUPER_UNIFIED, that will allow this.  (or say that it is allowed
> in UNIFIED and provide a third model called KIND_OF_UNIFIED, which is
> in between UNIFIED and SEPARATE).
>
> Other solutions are welcome.
>
> Irrespective of when we make the change of possibly adding an
> additional memory model (MPI-3.1, MPI-4, whatever), we should clarify
> the standard on what is allowed in MPI-3 and what is not, as an errata
> item.  Without that, it's confusing for implementors.
>
>  -- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> ______________________________**_________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi3-rma<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130730/9ce9b43b/attachment-0001.html>