<div class="gmail_quote">On Tue, Jan 10, 2012 at 16:23, Jie Chen <span dir="ltr"><<a href="mailto:jiechen@mcs.anl.gov">jiechen@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If using one sided operations, between every "do something" and "get data", I need to put a MPI_Win_fence() to synchronize processes. The fence works as barrier, meaning every process has to wait the slowest one to finish "do something" before it can get data from some other process. Since the work loads of "do something" are different among processes, I am concerned about the time wasted in the fence. </blockquote>
<div><br></div><div>Fence is not a good memory synchronization mechanism for this usage, but there are two other ways.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In fact, in this particular scenario, one sided operations offer no superiority over send/recv.</blockquote><div><br></div><div>Only that you don't need to determine how many accesses will occur.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is alternative to fence, namely MPI_Win_lock(); I am not sure if it would have such a barrier effect though.</blockquote></div><br><div>MPI_Win_lock() is not collective.</div><div><br></div><div>You can get a completion model with similar synchronization to point-to-point communication, but without needing to know the number of accesses to your window, with MPI_Win_post/start/complete/wait.</div>