[Mpi3-ft] Broken MPI_Request_free

[Greg Bronevetsky]

Actually, never mind. I didn't realize that Erez had already put this 
up into MPI 2.2. It looks like it won't get passed soon because its 
removal will break user programs but if we push for it in both the FT 
or the collectives working groups for 3.0, it'll make everybody's 
lives simpler.

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

At 08:52 AM 12/1/2008, Greg Bronevetsky wrote:
>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
>_______________________________________________
>mpi3-ft mailing list
>mpi3-ft at lists.mpi-forum.org
>http:// lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft