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

[Barrett, Brian W]

On 8/6/13 7:30 AM, "Jim Dinan" <james.dinan at gmail.com> wrote:

>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.

I tend to agree.  I also think the change can be quite small.  Section
11.4 (pg 436, line 37-38) already says that updates will eventually be
seen by a load in UNIFIED, meaning that the FLUSH/SYNC example that
started this thread already requires a SYNC in order to be correct (or a
while (!updated) loop).  So the primary thing we need to do is to clarify
that the "identical" refers to their view from memory, and not their view
from a reordering processor, so Sync (or other system-specific operations)
are required to force ordering.  This really feels like an erratum to me.

Brian

--
  Brian W. Barrett
  Scalable System Software Group
  Sandia National Laboratories
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 454 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130806/a2378ac3/attachment-0001.bin>