Ok, just a bit more and then I'll back down ;-) From what I've read, I think things are different in point-to-point because there are three different send modes (standard, buffered, or synchronous) that have different guarantees on whether completion is local or not (up to the MPI implementation, guaranteed local, guaranteed non-local, respectively). So far with collectives, we only have one completion mode (up to the MPI implementation). In fact, this very difference is why I find the phrase "local completion" to be confusing with collectives. As a reader, it sounds like there may be a mechanism for non-local completion (like MPI_Isbcast or something), but there is not (at least not yet). We have only one completion mode. I understand the intent here is to help the reader by stressing that when a collective completes at a process, there are no guarantess about the completion status of other processes. However, I think this is quite clear with our current text: p 2, lines 20-23 "The completion of a collective operation indicates that the caller is free to access locations in the communication buffer. It does not indicate that other processes in the group have completed or even started the operation (unless otherwise implied by the description of the operation)." and restated on p 50, lines 4-9 "Similarly to the blocking case, collective operations are considered to be complete when the local part of the operation is finished, i.e., the semantics of the operation are guaranteed and all buffers can be safely accessed and modified. Completion does not indicate that other processes have completed or even started the operation (unless otherwise implied by the description of the operation)." Personally, I just find the extra "local" keywords to be distracting. -Adam Bronis R. de Supinski wrote:
Adam:
Local completion is the term used in the point-to-point discussions. In particular, even MPI_Send has "local completion semantics", which means that the other side of the operation may not have completed. I think we should retain it since otherwise one can take it that the entire operation must complete (i.e., in all tasks).
Bronis
On Mon, 2 Feb 2009, Adam Moody wrote:
I think we could reduce "local completion" to just "completion" throughout the text. I don't think the adjective "local" is necessary and in some ways I find it confusing. We define precisely what "completion" means in a collective, and we also explicitly note that completion at a process does not indicate the status of other processes. Whenever we say "local completion", we really mean "completion" by our definition, so "local" is not necessary here. And by saying "local" completion, it sounds as a reader that there may be such a thing as "non-local" completion, but we don't define it. There is only one definition for collective completion. -Adam
p 2, line 17 in "Collective operations can (but are not required to) complete locally as soon as the caller's participation in the collective communication is finished." "complete locally" --> "complete"
p 2, line 20 in "The local completion of a collective operation indicates that the caller is free to access locations in the communication buffer." "The local completion" --> "The completion"
p 49, line 48 & p 50, line 1 in "Once initiated, all associated send buffers should not be modified and all associated receive buffers should not be accessed until the collective operation completes locally." "until the collective operation completes locally." --> "until the collective operation completes."
p 51, line 32 in "On intracommunicators, the operation completes locally after every process in the communicator called MPI_IBARRIER." "the operation completes locally" --> "the operation completes" and (to preserve verb tense) "after every process in the communicator called" --> "after every process in the communicator calls" _______________________________________________ mpi3-coll mailing list [email protected] http:// lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-coll
_______________________________________________ mpi3-coll mailing list [email protected] http:// lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-coll