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" <[email protected]> To: "MPI WG Remote Memory Access working group" <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: On Wed, Feb 5, 2014 at 11:57 AM, Balaji, Pavan <[email protected]> wrote:
On Feb 5, 2014, at 11:54 AM, Jeff Hammond <[email protected]> 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 [email protected] _______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] 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)