actually p. 42, ll. 44-46 in the 1.1 version of the document
> "... Similarly, a call to MPI_WAIT that completes a send will eventually
> return if a matching receive has been started, unless the receive is satisfied
> by another send, AND EVEN IF NO CALL IS EXECUTED TO COMPLETE THE RECEIVE."
> Replace "MPI_Send" by "MPI_ISend; MPI_Wait" in my example.
Yes, the non-blocking section says a lot more about completion than the
blocking section.
Let us also recognize the following expression expansion. An MPI_Ssend
is equivalent to an MPI_Send implemented with a short/long message
protocol and the short message size is zero.
First, from the blocking section, p. 38, ll. 10-12:
"However, the [synchronous] send will complete successfully only if
a matching receive is posted, and the receive operation has started
to receive the message sent by the synchronous send."
This implies that two actions are needed to complete the send:
1- The MPI_Irecv() posts the operation which means information has been
supplied about the operation.
2- The receive operation started to received the message. The
implementation may require something else to happen (e.g. any other
MPI call, not just completion calls) before actually "starting to
receive the message".
Then, from the non-blocking section, p. 36, ll. 47-48:
"A separate receive complete call is needed to complete the receive operation
and verify that the data has been received into the receive buffer."
X (completion) requires Y (complete call). So your receive is incomplete.
Let's say I have no system buffers. Therefore the message may still
reside in the sender's buffer. Therefore your send is incomplete.
and p. 37, ll. 16-17:
"If the send mode is synchronous, then the send can complete only if a
matching receive has started."
A matching receive is one prerequiste, not the full set of conditions.
This does not say it must complete on this one condition.
and p. 37, ll. 26-27:
"On the other hand, the [standard] send-complete may not complete until
a matching receive occurred, and the message was copied into the
receive buffer."
Again, there are two actions here. You have supplied the first action
but we have flexibility in taking the second (system) action.
Therefore the send-complete is allowed not to complete until the
second action is taken.
There are other useful quotes, but let's skip to yours, from the
"extended" definition of the progress semantic in 3.7.4.
> "... Similarly, a call to MPI_WAIT that completes a send will eventually
> return if a matching receive has been started, unless the receive is satisfied
> by another send, AND EVEN IF NO CALL IS EXECUTED TO COMPLETE THE RECEIVE."
I take this to mean one of the request completion calls, MPI_Wait*,
MPI_Test* and possibly MPI_Request_free. Other calls may be required
to allow the system to progress.
-=-
With all cards on the table, I'll allow that the standard suggests
that a while(1); after the MPI_Irecv will guarantee that the MPI_Send
will complete, which I'm sure is your position and desire and intent
if you in fact wrote the relevant sections.
My desire is to allow for simpler, peak efficient implementations on the
widest possible range of parallel hardware. This means no reliance on
interrupts to make MPI work. I am trying to demonstrate that there is
enough leeway in the standard to create fully compliant implementations
that rely exclusively on "in-line polling" (to extend your terminology).
We think this is a fine quality of MPI.
Now this all started with your position that MPI-2 extensions requiring
interrupts poses no serious complexity delta because proper implementations
already have such infrastructure. And I say no way.
-- Greg