[Mpi3-rma] MPI-3 UNIFIED model clarification

[Jeff Hammond]

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 <james.dinan at gmail.com> 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 <balaji at mcs.anl.gov> 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
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>
>
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma



-- 
Jeff Hammond
jeff.science at gmail.com