[Mpi3-ft] Broken MPI_Request_free

Greg Bronevetsky bronevetsky1 at llnl.gov
Mon Dec 1 10:52:47 CST 2008

A while ago we discussed how MPI_Request_free is hopelessly broken 
and should be removed from the MPI spec. The issue is coming back up 
in the MPI collectives group and I'd like to put together a short 
list of reasons for why we want to remove it. I recall the following:
- If there is an error in the original non-blocking operation, no 
clear place to return the error back to the application.
- On single-threaded architectures (BG/L CNK, Cray Catamount) it is 
completely possible for the non-blocking operation 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.
- Complicates compiler analysis of MPI applications because it is not 
clear from the source code when MPI is done with the application buffer.
- Unsafe since the fact that a message arrives at the destination 
processor does not guarantee that the OS on the sender processor has 
let go of the send buffer. As such, we need to either remove 
MPI_Request_free or be clearer about what message arrival implies 
about how MPI and the OS manage memory. (Erez, does this sound right?)

Can anybody think of other reasons?

Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1 at llnl.gov 

More information about the mpiwg-ft mailing list