Yes, but do we think the use case of never detecting completion is likely? I am not arguing for that, but rather that users might free the request but then detect completion another way, such as by waiting on the request on a subset of processes.
Jeff On Wed, Aug 12, 2020 at 5:40 PM Skjellum, Anthony <tony-skjel...@utc.edu> wrote: > FYI, one argument (also used to force us to add restrictions on MPI > persistent collective initialization to be blocking)... The > MPI_Request_free on an NBC poses a problem for the cases where there are > array types > posed (e.g., Alltoallv/w)... It will not be knowable to the application if > the vectors are in use by MPI still after > the free on an active request. We do *not* mandate that the MPI > implementation copy such arrays currently, so they are effectively "held as > unfreeable" by the MPI implementation till MPI_Finalize. The user cannot > deallocate them in a correct program till after MPI_Finalize. > > Another effect for NBC of releasing an active request, IMHO, is that you > don't know when send buffers are free to be deallocated or receive buffers > are free to be deallocated... since you don't know when the transfer is > complete OR the buffers are no longer used by MPI (till after MPI_Finalize). > > Tony > > > > > Anthony Skjellum, PhD > > Professor of Computer Science and Chair of Excellence > > Director, SimCenter > > University of Tennessee at Chattanooga (UTC) > > tony-skjel...@utc.edu [or skjel...@gmail.com] > > cell: 205-807-4968 > > > ------------------------------ > *From:* mpi-forum <mpi-forum-boun...@lists.mpi-forum.org> on behalf of > Jeff Hammond via mpi-forum <mpi-forum@lists.mpi-forum.org> > *Sent:* Saturday, August 8, 2020 12:07 PM > *To:* Main MPI Forum mailing list <mpi-forum@lists.mpi-forum.org> > *Cc:* Jeff Hammond <jeff.scie...@gmail.com> > *Subject:* Re: [Mpi-forum] MPI_Request_free restrictions > > 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@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@lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > -- Jeff Hammond jeff.scie...@gmail.com http://jeffhammond.github.io/
_______________________________________________ mpi-forum mailing list mpi-forum@lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
