[Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues
Richard Treumann
treumann at [hidden]
Thu Jul 17 16:29:36 CDT 2008
But the MPI standard says this is valid and can be used to avoid the need
to keep track of ISEND request handles. It is clear that if the matching
RECV has completed then the unaltered content of the ISEND buffer is no
longer needed. The RECV cannot have completed unless the message got out.
Erez is pointing out a case where the semantic stipulated by the MPI
standard back before RDMA adapters were available becomes flawed with the
way RDMA adapters now work. The content of the ISEND buffer is irrelevant
once the destination RECV has completed but some other things about the
ISEND buffer are still in limbo
Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
mpi-22-bounces_at_[hidden] wrote on 07/17/2008 05:14:42 PM:
> On Thu, Jul 17, 2008 at 03:46:59PM -0400, Richard Treumann wrote:
> > Sorry - the discussion is in the context of MPI_REQUEST_FREE.
> >
> > MPI_ISEND(question_buffer ..... request)
> > MPI_REQUEST_FREE(request)
> > MPI_RECV( reply_buffer)
> > free(question_buffer)
>
> Perhaps an implementer would dodge this bullet by having
> MPI_REQUEST_FREE do a MPI_CANCEL before freeing anything? That's
> assuming you have MPI_CANCEL on a send do the right thing.
>
> Thus, we turn this new can of worms into an existing can of
> worms. Voila!
>
> The example above strikes me as being undefined behavior in any case.
> I don't think we would guarantee that the message got out at all, and
> even if the remote side thinks the message is complete, that doesn't
> mean that the sender agrees the message is complete, without calling
> WAIT.
>
> -- greg
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080717/97068cec/attachment.html>
More information about the Mpi-22
mailing list