[Mpi3-rma] MPI-3 UNIFIED model clarification

[Pavan Balaji]

On 08/02/2013 04:45 PM, Underwood, Keith D wrote:
>>> At one point, them using their own memory fences was accepted as
>>> part of it, because it provides " the performance and "safety" of
>>> threads, localized to a window".  Those same people have to use
>>> memory fences for threads to work right too.
>>
>> Then what were you trying to say here:
>>
>>>>> Oh, I think we want it to say that they are identical.  I
>>>>> believe that is the only way to let the user actually use
>>>>> it.
>>
>> "identical" means located at the same memory address, but the user
>> is responsible for memory ordering if they don't use MPI_Win_sync?
>
> Yes - identical means "landing in the same physical memory and kept
> coherent".  The entire discussion about memory ordering is about
> cores doing aggressive reordering of instructions across boundaries
> that are unfriendly to multithreaded coding.  The place where we
> actually have a problem in the spec may be the ordering definition;
> however, I don't think we have a problem.  Delivering in order is
> still necessary for some use cases and it is not the fault of the API
> that a core has reordered loads.  It is the job of the user to deal
> with the fact that their core reorders those loads - just like they
> would have to in multithreaded programming.

It is OK to say that the user can use platform-specific techniques 
outside of MPI, but we need an MPI mechanism to do that as well.  I 
think we are arguing that MPI_Win_sync should be that mechanism.  That 
way, a program written for SEPARATE will stay correct for UNIFIED as well.

  -- Pavan

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji