[Mpi3-rma] request-based ops

[Jim Dinan]

Hey now, blocking doesn't mean that MPI /must/ block, it only means that it
/can/ block.  Blocking and synchronizing are certainly not the same; Ssend
synchronizes, which is a stronger semantic than blocking.

 ~Jim.


On Wed, Jun 12, 2013 at 5:07 PM, Jeff Hammond <jhammond at alcf.anl.gov> wrote:

> Sure, let's separate these issues.  I think Pirate RMA (RRPUT,
> RRACCUMULATE and RRRGET_ACCUMULATE) is a more _local_ solution in the
> MPI standard sense :-)
>
> SEND is also a nonblocking operation because the implementation can
> always buffer the data and return before the remote RECV is posted.
> Only SSEND is blocking if one asserts that blocking is equivalent to
> "requires remote agency to complete".
>
> So basically, I completely agree with the Forum back-pushers that
> IWIN_FLUSH etc. are as useful as ISEND.
>
> Jeff
>
> On Wed, Jun 12, 2013 at 4:58 PM, Pavan Balaji <balaji at mcs.anl.gov> wrote:
> >
> > 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
>
>
>
> --
> Jeff Hammond
> Argonne Leadership Computing Facility
> University of Chicago Computation Institute
> jhammond at alcf.anl.gov / (630) 252-5381
> http://www.linkedin.com/in/jeffhammond
> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
> ALCF docs: http://www.alcf.anl.gov/user-guides
> _______________________________________________
> 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/20130614/679b4d40/attachment-0001.html>