<div dir="ltr">On Thu, Aug 29, 2013 at 11:30 AM, Barrett, Brian W <span dir="ltr"><<a href="mailto:bwbarre@sandia.gov" target="_blank">bwbarre@sandia.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On 8/28/13 7:22 PM, "Pavan Balaji" <<a href="mailto:balaji@mcs.anl.gov" target="_blank">balaji@mcs.anl.gov</a>> wrote:<br>


<br>
><br>
>On 08/28/2013 03:47 PM, Barrett, Brian W wrote:<br>
>> And, further, I believe<br>
>> that:<br>
>><br>
>> X = 0<br>
>> Win_lock_all<br>
>> Recv<br>
>> do { compiler_fence(); } while (0 == X);<br>
>><br>
>> will eventually complete on any platform that supports UNIFIED, as the<br>
>> public and private copies are eventually consistent.  This gives us the<br>
>> behaviors necessary for implementing SHMEM on MPI-3.<br>
><br>
>Right, good point.  We could retain the definition that the public and<br>
>private windows will eventually be the same without additional MPI calls.<br>
><br>
>With that in mind, does requiring WIN_SYNC for immediate synchronization<br>
>of the two windows + a statement that there might be<br>
>implementation-specific ways (e.g., memory barriers) to do the same<br>
>sound reasonable from an OpenSHMEM point-of-view?<br>
<br>
</div>To me, yes.</blockquote><div><br></div><div>Isn't this the same semantic that we were already leaning toward?</div><div><br></div><div>From Aug. 6:</div><div><br></div><div>---8<---</div><div><br></div><div>
<div style="font-family:arial,sans-serif;font-size:13px">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.</div>
</div><div><br></div><div>---8<---<br></div><div><br></div><div>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.</div>
<div><br></div><div> ~Jim.</div></div></div></div>