[mpi3-coll] Simplify "local completion" to just "completion"
moody20 at llnl.gov
Mon Feb 2 17:06:50 CST 2009
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
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.
Bronis R. de Supinski wrote:
>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).
>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.
>>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
>> "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
>>mpi3-coll at lists.mpi-forum.org
>mpi3-coll mailing list
>mpi3-coll at lists.mpi-forum.org
More information about the mpiwg-coll