<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.<div>
<div><br></div><div style>�~Jim.</div></div></div><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 class="im"><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 class="im HOEnZb">
<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 class="HOEnZb"><div class="h5">
______________________________<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>