<div dir="ltr">An RMA origin process is only able to provide guarantees about what is done by the network, not what is observed by a thread in the target process.  My feeling on this is that it's up to the user to ensure that their architecture does what they want.  If the user wants to deal with replication, buffering, and reordering in the node in a portable way, they should use window synchronization.  If the user wants to leverage a hardware feature, that's fine too.  MPI doesn't define what should happen if you don't synchronize at the target, so the latter case is not invalid but also not portable.<div>
<br></div><div> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 2, 2013 at 11:42 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@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">"Underwood, Keith D" <<a href="mailto:keith.d.underwood@intel.com">keith.d.underwood@intel.com</a>> writes:<br>

<br>
</div><div class="im">> The point of UNIFIED was that we add a more useful model that worked<br>
> in *some* places.<br>
<br>
</div>Keith, should the standard include an example of UNIFIED that is<br>
portable, but does not call MPI_Win_sync?<br>
<br>
If so, what memory model should be assumed?  (C11 seems like a likely<br>
candidate, though I think the best quality documentation on these<br>
affairs is associated with the Linux kernel, and is readily implemented<br>
without language extensions.)<br>
<br>_______________________________________________<br>
mpi3-rma mailing list<br>
<a href="mailto:mpi3-rma@lists.mpi-forum.org">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/mailman/listinfo.cgi/mpi3-rma</a><br></blockquote></div><br></div>