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?
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/