<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<br><br>> 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. <div><br></div><div>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. </div><div><br></div><div>Thanks,</div><div>Vinod.</div><div><br></div><div>> <br>> > Thanks for listing these. If we are voting for this, my vote would be<br>> > to<br>> > have (2) and toss out (1) and (3).<br>> > <br>> > -- Pavan<br>> > <br>> > On 06/05/2010 02:40 PM, Underwood, Keith D wrote:<br>> > > I was only giving an example of how tightly ordering COULD be<br>> > defined. Ordering options include:<br>> > ><br>> > > 1) Ordering within a given replace: is the first byte guaranteed to<br>> > get there before the last?<br>> > > 2) Ordering between replaces to a given location: but, what if two<br>> > replaces are overlapping?<br>> > > 3) Ordering among all replaces to a given node<br>> > ><br>> > > Two sided gives you something weird, in that it orders the matching<br>> > of the message headers and not the end of messages or data within the<br>> > messages.<br>> > ><br>> > > Keith<br>> > ><br>> > >> -----Original Message-----<br>> > >> From: Pavan Balaji [mailto:balaji@mcs.anl.gov]<br>> > >> Sent: Saturday, June 05, 2010 3:30 PM<br>> > >> To: Underwood, Keith D<br>> > >> Cc: MPI 3.0 Remote Memory Access working group; bradc@cray.com<br>> > >> Subject: Re: [Mpi3-rma] mpi3-rma post from bradc@cray.com requires<br>> > >> approval<br>> > >><br>> > >><br>> > >> I see. My definition of ordering was a little bit different from<br>> > yours.<br>> > >><br>> > >> My definition was -- if I do two accumulates with replace on the<br>> > same<br>> > >> location, I'm guaranteed to have the second value in the location.<br>> > It<br>> > >> didn't have any definition of ordering to two different locations.<br>> > >><br>> > >> So, I think we need to come to a consensus first on what the actual<br>> > >> definition of ordering is.<br>> > >><br>> > >> -- Pavan<br>> > >><br>> > >> On 06/05/2010 02:22 PM, Underwood, Keith D wrote:<br>> > >>>>> We would need to think about whether we have to have the whole<br>> > >>>>> message ordered or ordered on a per target address basis.<br>> > >>>> Atomicity and ordering go hand-in-hand; if there's no atomicity,<br>> > >>>> ordering doesn't make sense. Since we have basic datatype<br>> > atomicity<br>> > >> for<br>> > >>>> accumulate/get_accumulate, ordering would make sense at that<br>> > >>>> granularity<br>> > >>>> as well.<br>> > >>>><br>> > >>>> If someone wants to propose full-message atomicity, then we can<br>> > >>>> consider<br>> > >>>> ordering at that granularity too. But till then, whole message<br>> > >> ordering<br>> > >>>> is an overkill.<br>> > >>> Well, they aren't orthogonal, but they aren't quite that tightly<br>> > >> linked. A user that knew that two messages were not going to<br>> > overlap<br>> > >> might want to use a full message ordering from a single node for<br>> > >> completion detection. E.g. an MPI_Accumulate() with "replace" to<br>> > one<br>> > >> buffer and then an MPI_Accumulate() to another buffer to increment a<br>> > >> variable and use the full message ordering to be able to use the<br>> > latter<br>> > >> for completion without the expense of a flush() between the<br>> > messages.<br>> > >> So, it has value and a usage scenario. I just don't know if we want<br>> > to<br>> > >> go that far or not.<br>> > >>> Keith<br>> > >> --<br>> > >> Pavan Balaji<br>> > >> http://www.mcs.anl.gov/~balaji<br>> > <br>> > --<br>> > Pavan Balaji<br>> > http://www.mcs.anl.gov/~balaji<br>> <br>> _______________________________________________<br>> mpi3-rma mailing list<br>> mpi3-rma@lists.mpi-forum.org<br>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma<br></div> </body>
</html>