[mpiwg-p2p] cancel in standard

[Balaji, Pavan]

Yes, I spoke loosely, but what I said doesn't change with that distinction.  "Matched" is a precursor to "received".

"If the user never posts a receive, the send cancel should always succeed."

However, if you interpret "received at the destination" to include unexpected queues, then one should not be able to cancel the request.

My interpretation is the former one.  But for either interpretation, the standard must be clarified.

  -- Pavan


On 6/3/15, 8:13 PM, "Sur, Sayantan" <sayantan.sur at intel.com> wrote:

>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."
>>>>>
>>>>>				
>>>>>			
>>>>>		
>>>>>	
>>>>>
>>>
>