Bitten by the migration :-)

-----Original Message----- From: Underwood, Keith D Sent: Monday, August 26, 2013 8:46 PM To: 'MPI 3.0 Remote Memory Access working group' Subject: RE: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model updates

Well, after asking somebody what happens with SHMEM on such architectures, I believe they basically tell the user "program this like you would a multithreaded program - all such rules apply". I don't see why we don't take that approach. It seems to me to be the closest to the objective of unified...

...

-----Original Message----- From: [email protected] [mailto:mpi3-rma- [email protected]] On Behalf Of Pavan Balaji Sent: Thursday, August 15, 2013 12:26 PM To: [email protected] Subject: Re: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model updates

Before I go out and start writing up the text for this, are there other comments on this?

Keith/Torsten/Jeff/Bill/Rajeev: thoughts?

On 08/06/2013 10:09 AM, Barrett, Brian W wrote:

...

On 8/6/13 7:30 AM, "Jim Dinan" <[email protected]> wrote:

...

My preference would be to have the fewer memory models in the standard. I prefer option #1 -- that a window synchronization (e.g. Win_sync) can be used to order load/store operations with respect to actions performed by other processes in the target's window. If no ordering is enforced, the MPI standard does not define what is seen by load operations at the target process. As a rationale, the local process' view of the window may not be consistent with the window because of performance optimizations or the consistency model of the underlying architecture. This would allow e.g. SHMEM implementations to still use MPI-3 RMA, but they would have to rely on a behavior that is defined by the architecture/implementation, as they currently do.

I think there's also a good chance that this could be an erratum, whereas a new memory model would have to go into a new version of the spec. If we were to decide later that we want a stronger memory model that defines the ordering seen by the target in the absence of synchronizations, this option would still allow us to add it later.

I tend to agree. I also think the change can be quite small. Section 11.4 (pg 436, line 37-38) already says that updates will eventually be seen by a load in UNIFIED, meaning that the FLUSH/SYNC example that started this thread already requires a SYNC in order to be correct (or a while (!updated) loop). So the primary thing we need to do is to clarify that the "identical" refers to their view from memory, and not their view from a reordering processor, so Sync (or other system-specific operations) are required to force ordering. This really feels like an erratum to me.

Brian

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

_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

-- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma