<div dir="ltr">Hi Brian,<div><br></div><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 style>MPI_Win_iflush</div><div style>MPI_Win_iflush_all</div><div style>MPI_Win_iflush_local</div><div style>MPI_Win_iflush_local_all</div><div style>MPI_Win_iunlock</div><div style>MPI_Win_iunlock_all</div>
<div style>MPI_Win_ifence</div><div style>MPI_Win_icomplete</div><div style>MPI_Win_iwait (to replace win_test, for completeness?)</div><div style><br></div><div style>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 style><br></div><div style> ~Jim.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 4:31 PM, 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"><div>On 6/17/13 9:38 AM, "Jim Dinan" <<a href="mailto:james.dinan@gmail.com" target="_blank">james.dinan@gmail.com</a>> wrote:</div>
<span><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">Hi Brian,
<div><br></div><div>Re: iunlock, ifence --</div><div><br></div><div>It might make sense to look at defining MPI_Win_test for these synchronization modes.  Some of the semantics might already be defined for us.</div></div>
</div></div></blockquote></span><div><br></div></div><div>I don't think so.  MPI_WIN_TEST is only defined for completing an access epoch of generalized active target.  It doesn't actually have the semantics you want, as it's almost a moving flush.  That is, a valid implementation would is to ask "does my started counter and ack counter match?", over and over, moving the target.  There's no splitting of an operation (the operation is "am i done?").  But MPI_WIN_FLUSH has much different semantics; you're splitting an operation into a start/complete, which means there's operation ordering / completion issues that don't exist with MPI_WIN_TEST.</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>