[mpiwg-p2p] cancel in standard

[Sur, Sayantan]

The standard distinguishes between “received” and “matched” very
carefully. For example, MPI_Ssend() can return when the message is matched
but not necessarily fully received.

"A send that uses the synchronous mode can be started whether or not a
matching
receive was posted. However, the 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."

Therefore, if the standard says “received”, I do not want to interpret
that as “matched”.

On 6/3/15, 8:03 PM, "Balaji, Pavan" <balaji at anl.gov> wrote:

>
>If you interpret received at the destination as "matched", then what I
>mentioned below holds -- if the user never posts a receive, the send
>cancel should always succeed.
>
>  -- Pavan
>
>
>
>
>On 6/3/15, 7:59 PM, "Sur, Sayantan" <sayantan.sur at intel.com> wrote:
>
>>+MPI P2P WG.
>>
>>We should probably discuss it in the P2P WG as well.
>>
>>I read the snippet of text and thought the “send” mentioned should
>>correspond to the MPI send operation (the one the user issued), and not
>>any internal buffering. “send completes normally” should mean the same
>>thing as sends completing as if cancel wasn’t called. Similarly,
>>“received
>>at the destination” should mean the normal way messages are received at
>>the destination i.e. by posting an MPI receive. Of course, these are my
>>interpretations :)
>>
>>On 6/3/15, 7:19 PM, "Balaji, Pavan" <balaji at anl.gov> wrote:
>>
>>>
>>>[Cc'ed the Forum]
>>>
>>>This wording has been debated many times at the Forum.  Specifically,
>>>the
>>>"completes normally" and "received at the destination" pieces are
>>>ambiguous.  For instance, if the data is copied into a bounce buffer,
>>>the
>>>send would complete normally, but that does not mean that there is a
>>>receive posted for that data.  In this case, it would be the user's
>>>responsibility to post a corresponding receive.  If the MPI
>>>implementation does not have a bounce buffer (e.g., for large messages),
>>>"received at the destination" could mean into an unexpected buffer, not
>>>necessarily a user buffer.
>>>
>>>The consensus from MPI-1 veterans (Marc, Bill, etc.) during the last
>>>discussion was that if the application does not post a receive, then it
>>>is guaranteed that the send should be cancelable.  At least that was the
>>>intent.  The wording, of course, is too vague for such a definition.
>>>
>>>You could try to weaken that interpretation and say that if the MPI
>>>implementation is not able to cancel a send operation, then the user is
>>>responsible for posting a matching receive to receive that data.
>>>Irrespective of which interpretation we go with, I think it is important
>>>to clarify it in the standard.  Perhaps an MPI-3.1 errata or MPI-3.2
>>>change instead of waiting for MPI-4?  Do you want to create a ticket?
>>>
>>>  -- Pavan
>>>
>>>
>>>
>>>
>>>On 6/3/15, 7:05 PM, "Sur, Sayantan" <sayantan.sur at intel.com> wrote:
>>>
>>>>What lines in the standard support the interpretation that “a message
>>>>that
>>>>will not be successfully matched, must be cancelable”?
>>>>
>>>>This is what I found, and it doesn’t support the stricter
>>>>interpretation.
>>>>
>>>>	
>>>>		
>>>>		
>>>>	
>>>>	
>>>>		
>>>>			
>>>>				
>>>>"If a
>>>>send is marked for cancellation, then it must be the case that either
>>>>the
>>>>send completes
>>>>normally, in which case the message sent was received at the
>>>>destination
>>>>process, or that
>>>>the send is successfully cancelled, in which case no part of the
>>>>message
>>>>was received at the
>>>>destination. Then, any matching receive has to be satisfied by another
>>>>send."
>>>>
>>>>				
>>>>			
>>>>		
>>>>	
>>>>
>>