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

[Barrett, Brian W]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130619/b3f1d217/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 454 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130619/b3f1d217/attachment-0001.bin>