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

[Jim Dinan]

Hi Brian,

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.

 ~Jim.


On Tue, Jun 18, 2013 at 4:31 PM, Barrett, Brian W <bwbarre at sandia.gov>wrote:

> On 6/17/13 9:38 AM, "Jim Dinan" <james.dinan at gmail.com> wrote:
>
> Hi Brian,
>
> Re: iunlock, ifence --
>
> 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.
>
>
> 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.
>
> 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/20130619/e3d9c1cd/attachment-0001.html>