On Thu, Aug 29, 2013 at 11:30 AM, Barrett, Brian W <[email protected]>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.

Isn't this the same semantic that we were already leaning toward?

From Aug. 6:

---8<--- 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. ---8<--- We never discussed removing the eventually synchronized semantic for unified windows. The only change was that MPI_WIN_SYNC should be used when the user wants "eventually" to be "now". If the platform ensures ordering through some other means, or a platform-specific non-MPI operation is used to order operations, that's fine, you are just relying on an extension for your platform. ~Jim.