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