<div dir="ltr">Here's a straw proposal on how we could fix this:<div><br></div><div style>1. Leave the "eventually" visible semantic as-is.</div><div style><br></div><div style>2. Add (as an erratum) a new semantic that defines the order of operations observed by load/store operations.  In this semantic, we would state that operations targeting a process' window region are not guaranteed to be observed by the target process in an ordering defined by the origin process.  To ensure that remotely completed operations are observed, the target process must call MPI_Win_sync().</div>
<div style><br></div><div style>I think this addresses many of our concerns (save "eventually," which is a bigger change), and should still be SHMEM compatible.  It also plugs a hole in the memory model for shared memory windows.</div>
<div style><br></div><div style> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 1, 2013 at 10:33 AM, Jim Dinan <span dir="ltr"><<a href="mailto:james.dinan@gmail.com" target="_blank">james.dinan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Let's make sure we are using the right language -- Unified does not guarantee that "public win == private win".  It guarantees that they are *eventually* the same, not immediately and always the same.  It is completely allowable for processes to have inconsistent views of the window (because there are cached copies of the data and buffered reads/writes).  The question we are debating is whether it is a reasonable semantic that those inconsistent views become eventually consistent without additional MPI calls by target processes.  And, if we choose to keep the "eventual" semantic that we currently have, whether any ordering imposed by other processes should be observed by the target process in load/store operations, provided that process performs no window synchronization calls.<span class="HOEnZb"><font color="#888888"><div>

<div><br></div><div> ~Jim.</div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 31, 2013 at 7:30 PM, Pavan Balaji <span dir="ltr"><<a href="mailto:balaji@mcs.anl.gov" target="_blank">balaji@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
On 07/31/2013 12:58 PM, Sur, Sayantan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/31/2013 12:00 PM, Jim Dinan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would bet that past Jim suggested striking the<br>
polling/eventually visibile clause and relying on window<br>
synchronization to see updates. :)<br>
</blockquote>
<br>
Yup, so did past, present, and future Pavan.  IMO, that's a useless<br>
guarantee.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The downside to this is that libraries like SHMEM that rely on<br>
passive progress and polling, would not be implementable on top<br>
of Unified.<br>
</blockquote>
<br>
It's pretty useless even for SHMEM, since the user doesn't know<br>
when the data is valid.  You could poll on a byte for it to turn to<br>
one, but at that point you only know about that one byte and<br>
nothing else.<br>
<br>
</blockquote>
<br>
Past Sayantan had missed this discussion, but present Sayantan does<br>
agree that "eventually" as defined is useless. But he is also<br>
confused by the guarantee given by MPI_Win_flush, that when the call<br>
returns, all previously issued RMA ops are complete locally and<br>
remotely + UNIFIED (public win == private win).<br>
</blockquote>
<br></div>
Unfortunately, that part slipped the checks of the folks who believed you need a WIN_SYNC.  So the standard is inconsistent.  We have now made a full circle and gotten back to where this email thread started :-).<div>
<br>
<br>
-- <br>
Pavan Balaji<br>
<a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br></div><div><div>
______________________________<u></u>_________________<br>
mpi3-rma mailing list<br>
<a href="mailto:mpi3-rma@lists.mpi-forum.org" target="_blank">mpi3-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/<u></u>mailman/listinfo.cgi/mpi3-rma</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>