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

Jim Dinan james.dinan at gmail.com
Wed Jun 19 09:58:07 CDT 2013

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

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.


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

More information about the mpiwg-rma mailing list