Adam, Christian, oh - this mail was delayed at my mailserver, ignore my reply to the previous one.

...

I very much appreciate many of your textual improvements. However, it is very time consuming for us as reviewers to keep track of such substantial changes. It would have been much easier, if you had contributed your changes in an earlier stage. Anyway, I waded through the changes to revision 3 and will comment only on the things that I don't like (consider everything else as excellent):

I second Torsten's opinion on p. 49, l. 35-37: This reformulation introduces three times the term "complete". Besides this drawback, I also don't see any benefit from this reformulation compared to the previous version.

It's a bit repetitive, I know. To make a direct parallel, I copied the same sentence structure used in the nonblocking point-to-point section (see the 2.1 document, page 47, lines 46-48). We could drop the "but does not complete it" clause to shorten this some (saves one "complete"): "A nonblocking start call initiates a collective operation, which must be completed in a separate completion call." ok, I revert my "might" if the point-to-point chapter mandates a completion function. I implemented your proposal from above.

...

p. 50, l. 1-2: Similar problem (i.e. 2x"complete"). May I propose: "The start call returns a request handle, which is eventually passed to a completion call."

I'd be ok with dropping a "complete" here, as well, although I prefer "which must be passed" over "which is eventually passed": "The start call returns a request handle, which must be passed to a completion call." sounds good - implemented this.

...

p. 50, l. 8: The part "unless otherwise specified in, or implied by, the description of the operation" has been added. Seem ok to me at first glance. However, we might re-check if this is really necessary and drop it otherwise.

I added the "implied by" to address cases like MPI_Alltoall, where there is no specified synchronization as in MPI_Barrier, but clearly a process can't complete until it has received data from every other process and thus knows all other processes have started the call. I have no objections to dropping one of these two phrases. Going with just "implied by" leads to a cyclic-sounding statement. "Completion does not imply that other processes have completed or even started the operation unless otherwise implied by the description of the operation." We could just go with "specified in": "Completion does not imply that other processes have completed or even started the operation unless otherwise specified in the description of the operation." I'm fine either way. The existing text in MPI-2.1 never mentiones this implied by, so I'll drop it (it should be intuitive).

...

p. 50, l. 17: The added postfix "to indicate any errors" seems wrong to me because MPI_SUCCESS is also a valid entry for the MPI_ERROR field. I'd propose to simply omit this postfix. However, I'm not 100% sure because the section about the MPI Status object looks quite confusing in this respect. Btw. there exists also an empty status (which sets all 3 fields) - so we might need to reconsider our decision about setting only the error field for nonblocking collective operations.

Yes, I agree, but I'll leave this alone as it is a bigger discussion for the group. we discussed that setting this would cause unnecessary overheads.

Best, 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