On Tue, Oct 30, 2012 at 8:07 AM, Barrett, Brian W <span dir="ltr"><<a href="mailto:bwbarre@sandia.gov" target="_blank">bwbarre@sandia.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb adM"><div class="im">On 10/30/12 9:00 AM, "Jed Brown" <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
<br>
>On Tue, Oct 30, 2012 at 6:54 AM, Torsten Hoefler <<a href="mailto:htor@illinois.edu">htor@illinois.edu</a>><br>
>wrote:<br>
><br>
>>>> I don't think  the target process can guarantee that the PUT is<br>
>>>> visible to a load/store  without an additional memory barrier.<br>
>>> The flush of the source process has to ensure that.<br>
>><br>
>> How?<br>
><br>
>See above, mfence.<br>
><br>
>Even in shared memory, the mfence is useless for guaranteeing visibility<br>
>to any other thread/process. For visibility on architectures that reorder<br>
>loads, the P1 must issue a read memory barrier after seeing the hand wave<br>
>and before reading from the window.<br>
<br>
</div></div>Right, so it's possible that on platforms that require a read barrier<br>
because they reorder loads, the MPI implementation will not be able to<br>
support the unified model.  Or they'll have to have a read barrier before<br>
every get in the unified model or some such thing.</blockquote></div><br><div>Right, I think it would be a cop-out to say that UNIFIED would not be supported there, thus the read memory barrier.</div>