On Mar 8, 2013, at 10:53 AM, George Bosilca <bosi...@icl.utk.edu> wrote:
> It depends. The usage of MPI is valid. Totally weird and absolutely > grotesque, but valid. What is invalid is the access of the array value. There > is no completion call for the irecv and no guarantee for completion on > MPI_Finalize, so making a decision on the content of buf[i] is incorrect. After thinking about this more, I don't think it's incorrect -- I think it's undefined. The description of MPI_FINALIZE doesn't say what happens for this case (and probably *shouldn't*). So it's undefined. The buf array *may* be filled and it may not. > I think the rationale for allowing MPI_Request_free was to take advantage of > the FIFO ordering for the match to allow the user to implement it's own > consistency protocols. Remember that Erez removed some bad AtoU about MPI_REQUEST_FREE in MPI-2; it's now MPI-3 p55:22-28: Advice to users. Once a request is freed by a call to MPI_REQUEST_FREE, it is not possible to check for the successful completion of the associated communication with calls to MPI_WAIT or MPI_TEST. Also, if an error occurs subsequently during the communication, an error code cannot be returned to the user — such an error must be treated as fatal. An active receive request should never be freed as the receiver will have no way to verify that the receive has completed and the receive buffer can be reused. (End of advice to users.) 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); > } 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. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
