[mpi3-coll] Nonblocking collectives standard draft

[Greg Bronevetsky]

>- 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
bronevetsky1 at llnl.gov