On Mar 8, 2013, at 17:37 , "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> wrote:
> He removed a bunch of text in the middle (see > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/143). In short: there is > NO way for a user to know when a REQUEST_FREEd request has completed, because > *matching* happens in order. In your example below, it's possible for the > Send to overtake the Isend, as long as the matching happened in order: > >> if (0 == rank) { >> MPI_Isend(buf, SIZE, MPI_CHAR, 1, 123, MPI_COMM_WORLD, &req); >> MPI_Request_free(&req); >> MPI_Send(buf, SIZE, MPI_CHAR, 1, 123, MPI_COMM_WORLD, &status); >> } else if (1 == rank) { >> MPI_Irecv(buf, SIZE, MPI_CHAR, 0, 123, MPI_COMM_WORLD, &req); >> MPI_Request_free(&req); >> MPI_Recv(buf, SIZE, MPI_CHAR, 0, 123, MPI_COMM_WORLD, &status); >> } Right, because both operations are non-blocking only the matching is important. Moreover, using MPI_Send instead of the MPI_Isend is not good either, as the MPI_Send does not guarantee completion. If we go for a MPI_Recv instead of the MPI_Irecv on the rank 1 first operation, my example become correct. > Regardless, this therefore probably makes a case for destroying something > when the refcount is 1. I had to stop working on that for the moment and > will likely get back to it next week -- I'll check and see what happens; it > may still be possible that those lists are empty when we close the PML, > anyway. Check pml_ob1_component.c:230. The commented out test seems to be doing what you look for, making sure that when the PML is closed no allocated requests are outside of the free list (like the matching or pending queues). George.
