<div dir="ltr"><div>So, we should define it as not defined?</div><div><br></div><div>OpenSHMEM itself does not define what should happen if you poll on a location that is the target of an RMA update.  The "proper" way to poll in SHMEM is to call one of the built-in polling functions (e.g. shmem_int_wait(location, value)), which can deal with the data consistency problem.<br>
</div><div><br></div><div> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 1:16 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 08/27/2013 11:39 AM, Jeff Hammond wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree with Keith. Losing SHMEM as a client of MPI-3 is not worth<br>
symmetry or other esoteric properties.<br>
<br>
It's entirely reasonable to say the standard leaves no-sync unified as<br>
undefined = implementation-defined. This would not be the first time.<br>
</blockquote>
<br></div>
Your statements are inconsistent.  You said you agree with Keith, but then said that the no-sync unified option should be undefined.  That's not what Keith is saying; he wants that to have *defined* behavior, i.e., it is valid for the client to do platform-specific memory consistency.<div class="HOEnZb">
<div class="h5"><br>
<br>
 -- Pavan<br>
<br>
-- <br>
Pavan Balaji<br>
<a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
______________________________<u></u>_________________<br>
mpiwg-rma mailing list<br>
<a href="mailto:mpiwg-rma@lists.mpi-forum.org" target="_blank">mpiwg-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/<u></u>mailman/listinfo.cgi/mpiwg-rma</a><br>
</div></div></blockquote></div><br></div>