On Mar 8, 2013, at 9:39 AM, George Bosilca <bosi...@icl.utk.edu> 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? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
