On Mon, Nov 24, 2008 at 09:34:09PM -0800, Greg Bronevetsky wrote:

...

- 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.

yes, we should probably bring this up again in the discussion of MPI-2.2. Let's talk about this on the telecon (I just put it on the agenda).

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. yes, I agree. I just wanted to stay consistent with the current standard with the text, but I don't like it either. I think we can't say that Request_free is generally bad, thu I chose this phrasing. However, I'm very open to changes. Can you propose a better wording?

Thanks, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Postdoctoral Researcher Open Systems Lab | Indiana University 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA Lindley Hall Room 135 | +01 (812) 855-3608