[Mpi3-rma] mpi3-rma post from bradc at cray.com requires approval

[Underwood, Keith D]

You are right, I should have chosen my words more carefully.  I believe we tossed ordering on MPI_Put when we tossed atomicity.  

I don't think we ever got to the discussion of what ordering would be for the atomics.  And, this is where life gets weird.  I'm not positive that you need ordering for atomics, except that they are the MPI_Puts you would actually use when you needed ordering.  So...  I will go back to... all UPC needs is ordering from one source to one target address.  I see three options:

1) Just define accumulates/get_accumulates to have the ordering that UPC needs
2) Default to the UPC ordering and allow an assert to relax that restriction.  This would be consistent with how the current one-sided operations handle locks
3) Add some other call to handle ordering, but we wouldn't want some call that you had to call with EVERY put or anything...  After all, all we need is relatively minimal ordering.

Keith

> -----Original Message-----
> From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-
> bounces at lists.mpi-forum.org] On Behalf Of balaji at mcs.anl.gov
> Sent: Sunday, May 30, 2010 10:56 AM
> To: MPI 3.0 Remote Memory Access working group
> Cc: bradc at cray.com
> Subject: Re: [Mpi3-rma] mpi3-rma post from bradc at cray.com requires
> approval
> 
> Keith,
> 
> The argument was against making MPI_Put more restrictive by requiring
> atomicity, since MPI_Accumulate with REPLACE already provides it. So, I
> think ordering is still important in this case.
> 
> With respect to ordering, again, I think the argument was against
> *only* ordered communication. I don't think there was opposition to
> providing both ordered and unordered.
> 
>  -- Pavan
> 
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> 
> ----- "Keith D Underwood" <keith.d.underwood at intel.com> wrote:
> 
> > Well, when Jeff and Bill successfully argued against a definition for
> > atomicity of access for conflicting accesses beyond "undefined", we
> > lost direct support for the UPC memory model.  After that, I no
> longer
> > cared about ordering and Jeff was still arguing vehemently against
> > ordering, so my understanding was that we had dropped ordering.  I am
> > not sure why we would support ordering without an access granularity
> > definition.
> >
> > Keith
> >
> >
> > ----- Original Message -----
> > From: mpi3-rma-bounces at lists.mpi-forum.org
> > <mpi3-rma-bounces at lists.mpi-forum.org>
> > To: MPI 3.0 Remote Memory Access working group
> > <mpi3-rma at lists.mpi-forum.org>
> > Cc: Brad Chamberlain <bradc at cray.com>
> > Sent: Sat May 29 22:38:03 2010
> > Subject: Re: [Mpi3-rma] mpi3-rma post from bradc at cray.com requires
> > approval
> >
> >
> > On 05/29/2010 06:24 AM, Underwood, Keith D wrote:
> > > 1) Ordering:
> > > 	a) Ordered from a given source to a given address on a given
> target
> > (unordered otherwise), or
> > > 	b) completely unordered
> >
> > My understanding was that we were providing both 1a and 1b. Or
> rather,
> >
> > MPI-2 already gives 1b, and we are proposing 1a together with it (not
> >
> > instead of it).
> >
> >   -- Pavan
> >
> > --
> > 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
> >
> > _______________________________________________
> > mpi3-rma mailing list
> > mpi3-rma at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma