[mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model updates

Jim Dinan james.dinan at gmail.com
Thu Aug 29 14:09:39 CDT 2013


On Thu, Aug 29, 2013 at 11:30 AM, Barrett, Brian W <bwbarre at sandia.gov>wrote:

> On 8/28/13 7:22 PM, "Pavan Balaji" <balaji at mcs.anl.gov> wrote:
>
> >
> >On 08/28/2013 03:47 PM, Barrett, Brian W wrote:
> >> And, further, I believe
> >> that:
> >>
> >> X = 0
> >> Win_lock_all
> >> Recv
> >> do { compiler_fence(); } while (0 == X);
> >>
> >> will eventually complete on any platform that supports UNIFIED, as the
> >> public and private copies are eventually consistent.  This gives us the
> >> behaviors necessary for implementing SHMEM on MPI-3.
> >
> >Right, good point.  We could retain the definition that the public and
> >private windows will eventually be the same without additional MPI calls.
> >
> >With that in mind, does requiring WIN_SYNC for immediate synchronization
> >of the two windows + a statement that there might be
> >implementation-specific ways (e.g., memory barriers) to do the same
> >sound reasonable from an OpenSHMEM point-of-view?
>
> To me, yes.


Isn't this the same semantic that we were already leaning toward?

>From Aug. 6:

---8<---

I prefer option #1 -- that a window synchronization (e.g. Win_sync) can be
used to order load/store operations with respect to actions performed by
other processes in the target's window.  If no ordering is enforced, the
MPI standard does not define what is seen by load operations at the target
process.  As a rationale, the local process' view of the window may not be
consistent with the window because of performance optimizations or the
consistency model of the underlying architecture.  This would allow e.g.
SHMEM implementations to still use MPI-3 RMA, but they would have to rely
on a behavior that is defined by the architecture/implementation, as they
currently do.

---8<---

We never discussed removing the eventually synchronized semantic for
unified windows.  The only change was that MPI_WIN_SYNC should be used when
the user wants "eventually" to be "now".  If the platform ensures ordering
through some other means, or a platform-specific non-MPI operation is used
to order operations, that's fine, you are just relying on an extension for
your platform.

 ~Jim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130829/9236deb3/attachment-0001.html>


More information about the mpiwg-rma mailing list