Yeah, all I ever wanted out of unified was eventual asynchronous arrival but when I was thinking about it in detail, I couldn't figure out how I could ever make use of this in a way that wouldn't look exactly like SEPARATE. Jeff On Tue, Jul 30, 2013 at 10:28 AM, Jim Dinan <[email protected]> wrote:
Hi Pavan,
I believe this is adequately specified on pg 436, line 37. P1 will *eventually* see the new value for "a" without any additional synchronization operations, but neither the flush by P0 nor the Recv by P1 guarantee that P1 will see the new value immediately.
~Jim.
On Sat, Jul 27, 2013 at 1:08 PM, Pavan Balaji <[email protected]> wrote:
Dear all,
We had some discussion on the semantics of UNIFIED in the past, that we were hoping to have clarified in MPI-3.1 or the errata. This email is to revive that discussion, so that we don't forget to address it.
Specifically, the concern was that some members of the WG believed that in the UNIFIED model, data is usable by the remote process after a PUT without an additional WIN_SYNC, while some members believed that it is not. Here's the example in question:
P0: Win_lock_all Put(a, P1) Flush MPI_Send(P1)
P1: Win_lock_all MPI_Recv(P0) read a
The question was whether the above program was valid without a WIN_SYNC on P1 between the Recv(P0) and "read a". If we want this to be valid in the UNIFIED model, only x86-like architectures can provide UNIFIED efficiently. Other architectures, such as PPC or ARM, that require an additional read barrier on P1 will not be able to provide UNIFIED even if they are cache-coherent, unless they add a memory barrier in every other MPI call (e.g., MPI_Recv in this case).
One possible solution we discussed was to clarify that this is not allowed in UNIFIED, but provide a third memory model called UBER_SUPER_UNIFIED, that will allow this. (or say that it is allowed in UNIFIED and provide a third model called KIND_OF_UNIFIED, which is in between UNIFIED and SEPARATE).
Other solutions are welcome.
Irrespective of when we make the change of possibly adding an additional memory model (MPI-3.1, MPI-4, whatever), we should clarify the standard on what is allowed in MPI-3 and what is not, as an errata item. Without that, it's confusing for implementors.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
-- Jeff Hammond [email protected]