On Tue, Feb 4, 2014 at 11:39 AM, Rolf Rabenseifner <[email protected]> wrote:

Brian and all,

No wording in the MPI-3.0 tells anything about the compiler problems. They are addressed by MPI_F_SYNC_REG (or work around with MPI_Get_address) to be sure that the store instruction is issued before I do any synchronization calls.

See MPI-3 Section 11.7.4. This is not new text. It's been there for years.

If I must do an additional MPI_WIN_SYNC, when must it be done?

Whenever you might have a race condition due to two threads or processes accessing the same memory via: - RMA + load/store - load/store on shared memory windows - RMA + non-RMA This may not be an inclusive list. Jeff

My example is simple: X is part of a shared memory window and should mean the same memory location in both processes

Process A Process B

x=13 MPI_F_SYNC_REG(X) MPI_Barrier MPI_Barrier MPI_F_SYNC_REG(X) print X

Where exactly do I need in which process an additional MPI_WIN_SYNC? Which wording in the MPI-3.0 does tell this need?

Best regards Rolf

----- Original Message -----

...

From: "Brian W Barrett" <[email protected]> To: "MPI WG Remote Memory Access working group" <[email protected]> Cc: "Stefan Andersson" <[email protected]>, "Bill Long" <[email protected]> Sent: Tuesday, February 4, 2014 6:06:02 PM Subject: Re: [mpiwg-rma] [EXTERNAL] Re: Synchronization on shared memory windows

On 2/4/14 9:59 AM, "Rolf Rabenseifner" <[email protected]> wrote:

...

Jeff,

thank you for the MPI_FREE_MEM hint. Yes, I'll fix it in my examples.

About the synchronization problems: If I use shared memory windows and direct remote load and store instead of the RMA functions PUT or GET, is it then correct, when I never use MPI_WIN-synchronization routines?

I would expect this, because in the unified RMA modell, the load and store accesses to the neighbors memory are done directly and MPI is not involved. Because of the unified RMA modell (must be for shared memory windows), there should be no need for cache flush routines. Correct?

No. Maybe. Sometimes.

Basically, unified is saying that the memory has the same eventually completeness that users have come to expect with shared memory programming. But what users have come to expect depends on the architecture and the programming language. So in some processor / language / compiler combinations, you might not need any synchronization. In other combinations, you might need compiler or processor memory barriers in your code. MPI guarantees, however, that MPI_WIN_SYNC will implement whatever compiler / processor memory barriers you need, so it can be used as the portable hammer in your toolchest of shared memory programming.

If you're only using load/stores in shared memory windows, you should not need the other synchronization routines (FLUSH, etc.).

Brian

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

_______________________________________________ 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) _______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

-- Jeff Hammond [email protected]