[Mpi3-rma] [EXTERNAL] Re: Memory barriers in MPI_WIN_LOCK_ALL mode
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>
> >>>> 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...
More information about the mpiwg-rma