[Mpi3-rma] [EXTERNAL] Re: Memory barriers in MPI_WIN_LOCK_ALL mode

Jed Brown jedbrown at mcs.anl.gov
Tue Oct 30 10:12:37 CDT 2012


On Tue, Oct 30, 2012 at 8:07 AM, Barrett, Brian W <bwbarre at sandia.gov>wrote:

> On 10/30/12 9:00 AM, "Jed Brown" <jedbrown at mcs.anl.gov> wrote:
>
> >On Tue, Oct 30, 2012 at 6:54 AM, Torsten Hoefler <htor at illinois.edu>
> >wrote:
> >
> >>>> I don't think  the target process can guarantee that the PUT is
> >>>> visible to a load/store  without an additional memory barrier.
> >>> The flush of the source process has to ensure that.
> >>
> >> How?
> >
> >See above, mfence.
> >
> >Even in shared memory, the mfence is useless for guaranteeing visibility
> >to any other thread/process. For visibility on architectures that reorder
> >loads, the P1 must issue a read memory barrier after seeing the hand wave
> >and before reading from the window.
>
> Right, so it's possible that on platforms that require a read barrier
> because they reorder loads, the MPI implementation will not be able to
> support the unified model.  Or they'll have to have a read barrier before
> every get in the unified model or some such thing.


Right, I think it would be a cop-out to say that UNIFIED would not be
supported there, thus the read memory barrier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20121030/7e3c0ff0/attachment-0001.html>


More information about the mpiwg-rma mailing list