Here's a refinement of the earlier draft erratum that incorporates this change: A window synchronization (e.g. MPI_WIN_SYNC, MPI_WIN_LOCK/UNLOCK, etc.) can be used to order load/store operations with respect to actions performed by other processes in the target's window. * In addition, an MPI implementation may also support the use of external operations to provide this ordering.* If no synchronization is performed, the ordering of load/store operations with respect to actions performed by other processes in the target's window is not defined. Rationale: The local process' view of the window may not be consistent with the window because of performance optimizations or the consistency model provided by the system. ~Jim. On Thu, Aug 29, 2013 at 3:17 PM, Pavan Balaji <[email protected]> wrote:

The only difference would be that we'll add there might be other implementation-specific ways to do the same.

-- Pavan

On Aug 29, 2013, at 10:30 AM, Barrett, Brian W wrote:

...

On 8/28/13 7:22 PM, "Pavan Balaji" <[email protected]> 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.

Brian

-- Brian W. Barrett Scalable System Software Group Sandia National Laboratories

_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma