On 6/19/13 8:58 AM, "Jim Dinan" <[email protected]> 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