[Mpi3-rma] MPI-3 UNIFIED model clarification

[Jeff Hammond]

Can someone argue that the overhead of calling WIN_SYNC is not trivial
and that the NO-OP implementation is expensive?  If not, why are we
talking about this?

Jeff

On Mon, Jul 29, 2013 at 3:58 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> Pavan Balaji <balaji at mcs.anl.gov> writes:
>> FLUSH will guarantee that the data is present in the remote public
>> memory.  And UNIFIED states that public memory == private memory.  So,
>> the user can read it directly without any additional MPI calls.
>>
>> That's the broken part.
>
> Modulo a memory barrier, depending on the architecture.
>
> Should the statement be strengthened so that the user must _either_ call
> MPI_Win_sync (with implementations expected to provide a fast path for
> UNIFIED) or perform any architecture-specific synchronization, which of
> course may piggyback on other synchronization, thus being lighter weight.
>
> Alternatively, add a new MPI function that does not take an MPI_Win
> argument and just performs a suitable memory fence.  This would make it
> explicit that UNIFIED does not need per-window synchronization.  Should
> MPI be in the business of providing basic memory fences, or is the user
> expected to get it from their language (C11/C++11), their own inline
> assembly, or third-party libraries like ConcurrencyKit?  As it is now,
> the user has to put in a fair bit of effort to write portable code with
> UNIFIED.
>
> _______________________________________________
> 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