[Mpi3-rma] [EXTERNAL] Re: request-based ops

[Jim Dinan]

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 at sandia.gov>wrote:

> On 6/19/13 8:58 AM, "Jim Dinan" <james.dinan at 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 at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130620/e0552581/attachment-0001.html>