<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><span id="OLK_SRC_BODY_SECTION"><div><div>On 6/19/13 8:58 AM, "Jim Dinan" <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:</div></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><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 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></div></div></blockquote></span><div><br></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><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></body></html>