<div dir="ltr">The MPI standard will not define by what mechanism the SHMEM implementation will establish the necessary consistency.  This is what I mean by undefined = implementation-defined.  I do not think that Keith is proposing to enumerate all processor memory models and the appropriate fences required to achieve the affect of win_sync but at lower cost.  Thus, it is the implementation - or perhaps more accurately, the platform on which the implementation resides - that will define these semantics.<div>

<br></div><div>Jeff</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 10:16 AM, 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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>
</div>