[Mpi3-rma] MPI-3 UNIFIED model updates

Sur, Sayantan sayantan.sur at intel.com
Tue Aug 6 09:54:08 CDT 2013


+1 to Jim's thoughts.

Sayantan

From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-bounces at lists.mpi-forum.org] On Behalf Of Jim Dinan
Sent: Tuesday, August 06, 2013 6:31 AM
To: MPI 3.0 Remote Memory Access working group
Subject: Re: [Mpi3-rma] MPI-3 UNIFIED model updates

Pavan,

Thanks for summarizing the discussion.

My preference would be to have the fewer memory models in the standard.  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.

I think there's also a good chance that this could be an erratum, whereas a new memory model would have to go into a new version of the spec.  If we were to decide later that we want a stronger memory model that defines the ordering seen by the target in the absence of synchronizations, this option would still allow us to add it later.

 ~Jim.
On Mon, Aug 5, 2013 at 10:20 PM, Pavan Balaji <balaji at mcs.anl.gov<mailto:balaji at mcs.anl.gov>> wrote:
All,

Based on the very long email thread on "MPI-3 UNIFIED model clarification", I think we now agree that something needs to change in the MPI standard to allow for cache-coherent architectures that don't quite give the level of hardware support that is required for UNIFIED.

We came down to one of two solutions for this --

1. We weaken the UNIFIED model to say that a WIN_SYNC is required for data to be used.  I liked Jim's wording best, so I'm listing it here:

Unified does not guarantee that "public win == private win".  It guarantees that they are *eventually* the same, not immediately and always the same.

I would add that the user can force the windows to be the same using WIN_SYNC, just like in SEPARATE.

2. We leave UNIFIED as-is, and create a new memory model.  I'm going to use KIND_OF_UNIFIED here for discussion, though someone else will need to come up with a better name eventually.

The KIND_OF_UNIFIED memory model would not have the above described semantics.

I, personally, am OK with either option.  But I look forward to hearing others thoughts on these models.

 -- Pavan

--
Pavan Balaji
http://www.mcs.anl.gov/~balaji
_______________________________________________
mpi3-rma mailing list
mpi3-rma at lists.mpi-forum.org<mailto:mpi3-rma at lists.mpi-forum.org>
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/20130806/16459a61/attachment-0001.html>


More information about the mpiwg-rma mailing list