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

[Rolf Rabenseifner]

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.

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

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" <bwbarre at sandia.gov>
> To: "MPI WG Remote Memory Access working group" <mpiwg-rma at lists.mpi-forum.org>
> Cc: "Stefan Andersson" <stefan at cray.com>, "Bill Long" <longb at cray.com>
> 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" <rabenseifner at hlrs.de> 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
> 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)