[Mpi3-rma] Memory barriers in MPI_WIN_LOCK_ALL mode

Pavan Balaji balaji at mcs.anl.gov
Tue Oct 30 09:15:39 CDT 2012


On 10/30/2012 09:13 AM, Underwood, Keith D wrote:
>>> Yes, win_synch is only needed in the separate model, which would then
>>> do a memory barrier. The MPI library has to guarantee that there is no
>>> inconsistency between public and private copy in the unified model (or
>>> it cannot claim that it supports unified).
>>
>> I'm not sure any architecture can do this without internally adding memory
>> barriers in a lot of MPI operations other than the usual FLUSH/SYNC/UNLOCK
>> type of operations.
>>
>> Note that the MPI standard only says that in the UNIFIED model, the data will
>> "eventually" appear (pg. 454, bullet item 6).  No guarantees that the data
>> actually is visible for load operations immediately after a flush.
>
> Ok, but, the kind of thing that delays that visibility (e.g. the
> uncertainty between when a posted write starts over PCIExpress and
> when it is known to be globally visible) is completely unaffected by
> a memory barrier.  Memory barrier until your heart is content and
> that thing could still be getting retried across a PCIExpress link
> and the process (and the NIC and other side of the link and just
> about anything else) would have no way to know...

Hmm.  Yes, you are right.  That's even worse though :-(.

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



More information about the mpiwg-rma mailing list