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

[Rolf Rabenseifner]

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:

--------------------
Example 11.13
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

MPI_WIN_LOCK_ALL(       MPI_WIN_LOCK_ALL(
MPI_MODE_NOCHECK,win)   MPI_MODE_NOCHECK,win) 

DO ...                  DO ...
  X=...
  MPI_F_SYNC_REG(X)
  MPI_WIN_SYNC(win)    
  MPI_Barrier             MPI_Barrier
                          MPI_WIN_SYNC(win)
                          MPI_F_SYNC_REG(X)
                          print X
END DO                  END DO

MPI_WIN_UNLOCK_ALL(win) MPI_WIN_UNLOCK_ALL(win)
--------------------

Is the text okay?
Any text correctons needed?

Rolf

----- 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>
> wrote:
> >
> > 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
> an
> 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
> 
> --
> Jeff Hammond
> jeff.science at gmail.com
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

-- 
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)