<div dir="ltr">Pavan,<div><br></div><div>Thanks for summarizing the discussion.</div><div><br></div><div>My preference would be to have the fewer memory models in the standard.  I prefer option #1 -- that a window synchronization (e.g. Win_sync) can be used to order load/store operations with respect to actions performed by other processes in the target's window.  If no ordering is enforced, the MPI standard does not define what is seen by load operations at the target process.  As a rationale, the local process' view of the window may not be consistent with the window because of performance optimizations or the consistency model of the underlying architecture.  This would allow e.g. SHMEM implementations to still use MPI-3 RMA, but they would have to rely on a behavior that is defined by the architecture/implementation, as they currently do.</div>
<div><br></div><div class="gmail_extra">I think there's also a good chance that this could be an erratum, whereas a new memory model would have to go into a new version of the spec.  If we were to decide later that we want a stronger memory model that defines the ordering seen by the target in the absence of synchronizations, this option would still allow us to add it later.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"> ~Jim.<br><br><div class="gmail_quote">On Mon, Aug 5, 2013 at 10:20 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">All,<br>
<br>
Based on the very long email thread on "MPI-3 UNIFIED model clarification", I think we now agree that something needs to change in the MPI standard to allow for cache-coherent architectures that don't quite give the level of hardware support that is required for UNIFIED.<br>

<br>
We came down to one of two solutions for this --<br>
<br>
1. We weaken the UNIFIED model to say that a WIN_SYNC is required for data to be used.  I liked Jim's wording best, so I'm listing it here:<br>
<br>
Unified does not guarantee that "public win == private win".  It guarantees that they are *eventually* the same, not immediately and always the same.<br>
<br>
I would add that the user can force the windows to be the same using WIN_SYNC, just like in SEPARATE.<br>
<br>
2. We leave UNIFIED as-is, and create a new memory model.  I'm going to use KIND_OF_UNIFIED here for discussion, though someone else will need to come up with a better name eventually.<br>
<br>
The KIND_OF_UNIFIED memory model would not have the above described semantics.<br>
<br>
I, personally, am OK with either option.  But I look forward to hearing others thoughts on these models.<span class="HOEnZb"><font color="#888888"><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>
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>
</font></span></blockquote></div><br></div></div>