[Mpi-forum] MPI_Request_free restrictions
Jim Dinan
james.dinan at gmail.com
Wed Aug 12 15:51:28 CDT 2020
IIRC, the argument for RMA was that we had not wanted to require the MPI
library to maintain a reference to the request. There could be many RMA
operations pending and the MPI library maintaining a list of pending
operations could be a significant source of overhead. I seem to recall this
having been the general sentiment at the time and it may have also applied
to NBC.
~Jim.
On Sat, Aug 8, 2020 at 7:15 PM Jeff Hammond via mpi-forum <
mpi-forum at lists.mpi-forum.org> wrote:
> We should fix the RMA chapter with an erratum. I care less about NBC but
> share your ignorance of why it was done that way.
>
> Sent from my iPhone
>
> On Aug 8, 2020, at 6:51 AM, Balaji, Pavan via mpi-forum <
> mpi-forum at lists.mpi-forum.org> wrote:
>
> Folks,
>
> Does someone remember why we disallowed users from calling
> MPI_Request_free on nonblocking collective requests? I remember the
> reasoning for not allowing cancel (i.e., the operation might have completed
> on some processes, but not all), but not for Request_free. AFAICT,
> allowing the users to free the request doesn’t make any difference to the
> MPI library. The MPI library would simply maintain its own refcount to the
> request and continue forward till the operation completes. One of our
> users would like to free NBC requests so they don’t have to wait for the
> operation to complete in some situations.
>
> Unfortunately, when I added the Rput/Rget operations in the RMA chapter, I
> copy-pasted that text into RMA as well without thinking too hard about it.
> My bad! Either the RMA committee missed it too, or they thought of a
> reason that I can’t think of now.
>
> Can someone clarify or remind me what the reason was?
>
> Regards,
>
> — Pavan
>
> MPI-3.1 standard, page 197, lines 26-27:
>
> “It is erroneous to call MPI_REQUEST_FREE or MPI_CANCEL for a request
> associated with a nonblocking collective operation.”
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20200812/e7ce4cfa/attachment.html>
More information about the mpi-forum
mailing list