[mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model updates

[Underwood, Keith D]

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: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-
> > bounces at lists.mpi-forum.org] On Behalf Of Pavan Balaji
> > Sent: Thursday, August 15, 2013 12:26 PM
> > To: mpi3-rma at lists.mpi-forum.org
> > 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" <james.dinan at gmail.com> 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
> > > mpi3-rma at lists.mpi-forum.org
> > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> > >
> >
> > --
> > Pavan Balaji
> > http://www.mcs.anl.gov/~balaji
> > _______________________________________________
> > mpi3-rma mailing list
> > mpi3-rma at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma