<div dir="ltr">I agree with the general statement that the nonblocking call marks the end of the epoch.  In the case of MPI_Win_test, it's trying to close an exposure epoch -- not an access epoch -- so communication operations from the origin process are not being completed by synchronization (although, the test/wait synchronization could be waiting for a self communication, that operation is completed by start/complete not post/wait).  I think an MPI_Win_iwait operation that uses the semantic you described should be identical to MPI_Win_test.  Unless I'm missing something, which never happens when discussing RMA.  :)<div>
<br></div><div> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 10:34 AM, Barrett, Brian W <span dir="ltr"><<a href="mailto:bwbarre@sandia.gov" target="_blank">bwbarre@sandia.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div class="im"><span><div><div>On 6/19/13 8:58 AM, "Jim Dinan" <<a href="mailto:james.dinan@gmail.com" target="_blank">james.dinan@gmail.com</a>> wrote:</div>
</div><div><br></div><blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5"><div><div><div dir="ltr"><div>I think we're in agreement that iflush needs to be defined separately.  I was thinking out loud (without really thinking that hard about it) that win_test might be usable to achieve iunlock or ifence, but this is nonsensical because the arguments are different
 across these functions.  Win_test also only covers win_wait.  To be complete, we should also consider MPI_Win_icomplete, and a few others.  Here's a more exhaustive list:</div><div><br></div><div>MPI_Win_iflush</div>
<div>MPI_Win_iflush_all</div><div>MPI_Win_iflush_local</div><div>MPI_Win_iflush_local_all</div><div>MPI_Win_iunlock</div><div>MPI_Win_iunlock_all</div><div>MPI_Win_ifence</div><div>MPI_Win_icomplete</div><div>MPI_Win_iwait (to replace win_test, for completeness?)</div>
<div><br></div><div>This is a whole other can of worms, but in some cases, the functions that start an epoch can block (e.g. a lock operation when load/store is possible for the target).  I don't know to what extent we want to look into nonblocking variants of those
 routines. We already have nonblocking fence in the list, which initiates an epoch.</div></div></div></div></blockquote></span><div><br></div></div><div>I think MPI_WIN_IWAIT would have very different semantics than MPI_WIN_TEST.  Again, I think the only sane way to define non-blocking synchronization functions is to say essentially that the non-blocking function starts the synchronization (ends the epoch from the programmers standpoint) and the successfully completed request ends the synchronization (starts the next epoch or allows new epochs to be started, depending on the synchronization).  Anything else is nightmarish from either a programmer's standpoint (non-blocking can block) or an implementor's standpoint (must suddenly track requests much more fine-grained than today, killing performance).</div>
<div class="im"><div><br></div><div>Brian</div><div><div><div><br></div><div><div><div><div style="font-family:Consolas;font-size:medium">--</div><div style="font-family:Consolas;font-size:medium">  Brian W. Barrett</div>
<div style="font-family:Consolas;font-size:medium">  Scalable System Software Group</div><div style="font-family:Consolas;font-size:medium">  Sandia National Laboratories</div></div></div></div></div></div></div></div>
<br>_______________________________________________<br>
mpi3-rma mailing list<br>
<a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br></blockquote></div><br></div>