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 <balaji@mcs.anl.gov> 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" <balaji@mcs.anl.gov> 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
> mpiwg-rma@lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

_______________________________________________
mpiwg-rma mailing list
mpiwg-rma@lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma