This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Mar 8, 2013, at 15:56 , "Jeff Squyres (jsquyres)" <jsquyres_at_[hidden]> wrote:
> On Mar 8, 2013, at 9:39 AM, George Bosilca <bosilca_at_[hidden]> wrote:
>> I have a more advanced use case for you. Based on the MPI standard, MPI_Finalize can be called while the user still has non-complete requests returned by any of the non-blocking calls (there are some drawbacks of course, but this is not specifically prohibited).
> Actually, it is prohibited by MPI-3 p359:41-48:
> Before an MPI process invokes MPI_FINALIZE, the process must perform all MPI calls needed to complete its involvement in MPI communications: It must locally complete all MPI operations that it initiated and must execute matching calls needed to complete MPI communications initiated by other processes. For example, if the process executed a non- blocking send, it must eventually call MPI_WAIT, MPI_TEST, MPI_REQUEST_FREE, or any derived function; if the process is the target of a send, then it must post the matching receive; if it is part of a group executing a collective operation, then it must have completed its participation in the operation.
>> Thus, these requests will not have a ref count to 1, so they will not be able to be destructed. This is exactly what our code is doing today:
>> pml_base_close.c:58: OBJ_DESTRUCT(&mca_pml_base_send_requests);
>> pml_base_close.c:59: OBJ_DESTRUCT(&mca_pml_base_recv_requests);
>> and then ompi_freelist.c:86.
> If the app REQUEST_FREE'd a nonblocking send/receive, don't we block in ompi_mpi_finalize() before the call to pml_base_close(), such that the PMLs will be drained before we get to destroying the PMLs?
We don't, as we have no way of knowing there are pending requests in the pipeline. There is a separation between who create the requests and who release them. They are created by the selected PML, and are destroyed by the base, after the selected PML has been turned off.
> Jeff Squyres
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> devel mailing list