[mpiwg-rma] [EXTERNAL] Re: Synchronization on shared memory windows

[Barrett, Brian W]

On 2/4/14 11:01 AM, "Rolf Rabenseifner" <rabenseifner at hlrs.de> wrote:

>The MPI_WIN_SYNC (not the Fortran MPI_F_SYNC_REG)
>has no meaning in the unified memory model if all accesses
>are done without RMA routines.
>It has only a meaning if different public and privat copy is
>there (MPI-3.0 p450:46-p451:2).
>MPI-3.0 p456:3 - p457:7 define the rules for the unified memory model
>but there is no need to use MPI_WIN_SYNC.

Right, there's no need from an MPI point of view, but that doesn't mean
that the language/compiler/processor doesn't have a need for extra
synchronization.

>The combination of X=13 and MPI_F_SYNC_REG(X)
>before MPI_Barrier should guarantee that all bytes of X are
>stored in memory. The same should be valid in C,
>because the C compiler has no chance to see whether
>MPI_Barrier will access the bytes of X or not.
>And if it is guaranteed to be in the unified memory,
>then the other process (B) should be able to correctly
>read the data after the return from its barrier.
>
>What is wrong with my thinking?
>Which detail do I miss?

According to my reading of the spec, MPI_F_SYNC_REG only prevents the
language/compiler from moving the store, but does not say anything about
processor ordering.  So the WIN_SYNC in my last e-mail will add the
processor memory barrier, which will give you all the semantics you need.

Shared memory programming is a disaster in most languages today, so we
decided to pass that disaster on to the user.  We really can't help,
without adding lots of overhead (ie, using put/get/rma synchronization).
So if a user already knows how to do shared memory programming, this will
feel natural.  If they don't, it's going to hurt badly :/.


Brian

--
  Brian W. Barrett
  Scalable System Software Group
  Sandia National Laboratories