[mpiwg-rma] [EXTERNAL] Re: Synchronization on shared memory windows
rabenseifner at hlrs.de
Wed Feb 5 12:36:11 CST 2014
MPI-3.0 p449:9 requires a passive target epoch when you want to call MPI_WIN_SYNC.
I do not see need to change the rules of MPI-3, because the shared lock
does not hurt.
I would only add the following example at the end of 11.7:
The following example demonstrates the rules for the unified memory model if the data transfer is implemented only with load and store (instead of MPI_PUT or MPI_GET) and the synchronization between the processes is done with MPI communication (instead of RMA synchronization routines).
The used synchronization must be supplemented with MPI_WIN_SYNC which acts only local as a processor-memory-barrier.
For MPI_WIN_SYNC, a passive target epoch is established with MPI_WIN_LOCK_ALL.
X is part of a shared memory window and should be the same memory location in both processes.
Process A Process B
DO ... DO ...
END DO END DO
Is the text okay?
Any text correctons needed?
----- Original Message -----
> From: "Jeff Hammond" <jeff.science at gmail.com>
> To: "MPI WG Remote Memory Access working group" <mpiwg-rma at lists.mpi-forum.org>
> Sent: Wednesday, February 5, 2014 7:25:19 PM
> Subject: Re: [mpiwg-rma] [EXTERNAL] Re: Synchronization on shared memory windows
> On Wed, Feb 5, 2014 at 12:14 PM, Balaji, Pavan <balaji at anl.gov>
> > OK, I thought you were referring to a generic memory barrier call,
> > not
> > related to the window.
> > In what case will you need this call outside the epoch, given that
> > you can
> > only access the window content in an epoch?
> > On Feb 5, 2014 12:06 PM, Jeff Hammond <jeff.science at gmail.com>
> > wrote:
> > On Wed, Feb 5, 2014 at 11:57 AM, Balaji, Pavan <balaji at anl.gov>
> > wrote:
> >> On Feb 5, 2014, at 11:54 AM, Jeff Hammond <jeff.science at gmail.com>
> >> wrote:
> >>> I think advice to users regarding WIN_SYNC wouldn't hurt given
> >>> that
> >>> some of us are talking about it as if it is a portable
> >>> abstraction for
> >>> a memory barrier when it is now only correct to use it within an
> >>> RMA
> >>> sync epoch. Or we need to relax this restriction.
> >> Without this restriction, there’s no connection to what memory is
> >> being
> >> made consistent with the WIN_SYNC call. I’d be against removing
> >> it.
> > The memory being made consistent is obviously the public and
> > private
> > window. In the case of UNIFIED, it's just a memory barrier.
> > Right?
> > I suppose someone could always WIN_LOCK+WIN_SYNC+WIN_UNLOCK as a
> > portable abstraction for a memory barrier in the case where an
> > epoch
> > is not already established.
> Does load-store against a shared memory window have to be inside of
> epoch? I can't remember but if it does, then shared memory windows
> are not the magic abstraction for POSIX shm that I though they were.
> Jeff Hammond
> jeff.science at gmail.com
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)
More information about the mpiwg-rma