[Mpi3-rma] MPI-3 UNIFIED model updates

Jeff Hammond jeff.science at gmail.com
Tue Aug 6 09:15:57 CDT 2013

I agree with Jim on all counts.

SHMEM has never been rigorously standardized hence they lose nothing here.

OpenSHMEM is still working out the kinks so I don't know how they'll deal
with this in their spec, if at all.


Sent from my iPhone

On Aug 6, 2013, at 8:31 AM, Jim Dinan <james.dinan at gmail.com> wrote:


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.


On Mon, Aug 5, 2013 at 10:20 PM, Pavan Balaji <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
> http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi3-rma<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma>

mpi3-rma mailing list
mpi3-rma at lists.mpi-forum.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130806/39cae8f4/attachment-0001.html>

More information about the mpiwg-rma mailing list