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

[Pavan Balaji]

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