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.  :)

 ~Jim.


On Wed, Jun 19, 2013 at 10:34 AM, Barrett, Brian W <bwbarre@sandia.gov> wrote:
On 6/19/13 8:58 AM, "Jim Dinan" <james.dinan@gmail.com> wrote:

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:

MPI_Win_iflush
MPI_Win_iflush_all
MPI_Win_iflush_local
MPI_Win_iflush_local_all
MPI_Win_iunlock
MPI_Win_iunlock_all
MPI_Win_ifence
MPI_Win_icomplete
MPI_Win_iwait (to replace win_test, for completeness?)

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.

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).

Brian

--
  Brian W. Barrett
  Scalable System Software Group
  Sandia National Laboratories

_______________________________________________
mpi3-rma mailing list
mpi3-rma@lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma