[Mpi3-rma] request-based ops

[Pavan Balaji]

The push-back at the Forum was that WIN_FLUSH and WIN_UNLOCK are local 
operations (in MPI's definition of local), so they are already 
nonblocking.  I was not at the Forum.  I pointed out to Wesley after he 
returned that they are only local in the simple case where no one else 
is holding the lock.  Otherwise they are not.

Further, the proposal is not only about WIN_FLUSH and WIN_UNLOCK.  It 
was for a long list of blocking functions: COMM_ACCEPT, COMM_CONNECT, 
WIN_FENCE, WIN_COMPLETE, WIN_WAIT, WIN_UNLOCK, WIN_FLUSH, 
WIN_FLUSH_LOCAL, WIN_FLUSH_ALL, WIN_FLUSH_LOCAL_ALL, ...  The point was 
that MPI should deal with concepts, not specific function exceptions. 
Nonblocking communication is one such concept, and it should be valid 
for all operations (that are not local).

FWIW, my proposal was only to add nonblocking variants to blocking 
calls.  Adding extra per-op remote completion requests is a separate 
issue and should not be mixed with this.  I personally think it's useful 
(in fact, my original proposal for RPUT/RGET equivalents had it), but 
that's still a separate issue.

  -- Pavan

On 06/12/2013 09:41 AM, Jeff Hammond wrote:
> So Wes was telling me about IWIN_FLUSH yesterday (this function is a
> great idea, btw) and the alternative of adding double-request RPUT and
> RACCUMULATE that provide a request for both local and remote
> completion.  By induction, this would imply a triple-request
> RGET_ACCUMULATE operation, which I also think is a good idea.  It's
> really silly to have to wait for the result buffer to be ready to
> reuse the origin buffer in RGET_ACCUMULATE.  It seems that many
> implementations will be able to send the entire origin buffer a
> nontrivial amount of time before the result comes back, particularly
> if the remote side doesn't have hardware-based progress and the data
> has to wait in a network buffer.
>
> I'm sorry that I missed the last day of the Forum in San Jose.  I
> didn't know these operations were on the table.  They sound like a
> great idea to me.
>
> Jeff
>

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji