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

[Vinod tipparaju]

> I tend to agree that (2) is what is critical, but both (1) & (2) may be important.  The problem with not having (1) is that it gets significantly more expensive to figure out when a message has been delivered.  <shrug> that may be ok, but may be a pain. 
Seems like (2) is the most useful to support. As far as (1), is probably not safe to ever legally allow a user poll on a last byte to check for message being delivered; it also is a heavy weight process to give this guarantee when a system doesn't. 
Thanks,Vinod.
> 
> > Thanks for listing these. If we are voting for this, my vote would be
> > to
> > have (2) and toss out (1) and (3).
> > 
> >   -- Pavan
> > 
> > On 06/05/2010 02:40 PM, Underwood, Keith D wrote:
> > > I was only giving an example of how tightly ordering COULD be
> > defined.  Ordering options include:
> > >
> > > 1) Ordering within a given replace:  is the first byte guaranteed to
> > get there before the last?
> > > 2) Ordering between replaces to a given location:  but, what if two
> > replaces are overlapping?
> > > 3) Ordering among all replaces to a given node
> > >
> > > Two sided gives you something weird, in that it orders the matching
> > of the message headers and not the end of messages or data within the
> > messages.
> > >
> > > Keith
> > >
> > >> -----Original Message-----
> > >> From: Pavan Balaji [mailto:balaji at mcs.anl.gov]
> > >> Sent: Saturday, June 05, 2010 3:30 PM
> > >> To: Underwood, Keith D
> > >> Cc: MPI 3.0 Remote Memory Access working group; bradc at cray.com
> > >> Subject: Re: [Mpi3-rma] mpi3-rma post from bradc at cray.com requires
> > >> approval
> > >>
> > >>
> > >> I see. My definition of ordering was a little bit different from
> > yours.
> > >>
> > >> My definition was -- if I do two accumulates with replace on the
> > same
> > >> location, I'm guaranteed to have the second value in the location.
> > It
> > >> didn't have any definition of ordering to two different locations.
> > >>
> > >> So, I think we need to come to a consensus first on what the actual
> > >> definition of ordering is.
> > >>
> > >>   -- Pavan
> > >>
> > >> On 06/05/2010 02:22 PM, Underwood, Keith D wrote:
> > >>>>> We would need to think about whether we have to have the whole
> > >>>>> message ordered or ordered on a per target address basis.
> > >>>> Atomicity and ordering go hand-in-hand; if there's no atomicity,
> > >>>> ordering doesn't make sense. Since we have basic datatype
> > atomicity
> > >> for
> > >>>> accumulate/get_accumulate, ordering would make sense at that
> > >>>> granularity
> > >>>> as well.
> > >>>>
> > >>>> If someone wants to propose full-message atomicity, then we can
> > >>>> consider
> > >>>> ordering at that granularity too. But till then, whole message
> > >> ordering
> > >>>> is an overkill.
> > >>> Well, they aren't orthogonal, but they aren't quite that tightly
> > >> linked.  A user that knew that two messages were not going to
> > overlap
> > >> might want to use a full message ordering from a single node for
> > >> completion detection.  E.g. an MPI_Accumulate() with "replace" to
> > one
> > >> buffer and then an MPI_Accumulate() to another buffer to increment a
> > >> variable and use the full message ordering to be able to use the
> > latter
> > >> for completion without the expense of a flush() between the
> > messages.
> > >> So, it has value and a usage scenario.  I just don't know if we want
> > to
> > >> go that far or not.
> > >>> Keith
> > >> --
> > >> Pavan Balaji
> > >> http://www.mcs.anl.gov/~balaji
> > 
> > --
> > 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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20100605/71035cb6/attachment-0001.html>