- another argument _for_ MPI_REQUEST_FREE is the existence of intercommunicators where all processes (i.e., in group A and in group B) have to call the collective but only part of them might be involved (e.g., for MPI_IBCAST all but the root process in group A don't really participate in the operation - they pass MPI_PROC_NULL as root argument). So having a lightweight MPI_Wait alternative might not be too bad ...

I would argue against MPI_Request_free in general for both point-to-point and collective operations. For one thing, if there is an error during the operation, MPI has no logical place to deliver this notification. Another reason is that on single-threaded architectures (BG/L CNK, Cray Catamount) it is completely possible for the non-blocking to not complete until MPI_Finalize because the application is not required to issue any more MPI calls during which progress may be made on the communication. At least if we have no MPI_Request_free the user is eventually required to call MPI_Test or MPI_Wait to ensure progress. I can go on but MPI_Request_free is bad. Having said that, I object to the text that explains the reasoning for removing MPI_Request_free on page 50 for exactly the reason above. We shouldn't have MPI_Request_free because its generally bad. Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 [email protected]