<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; "><div>On 6/17/13 9:38 AM, "Jim Dinan" <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:</div><span id="OLK_SRC_BODY_SECTION"><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">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>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><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>