[Mpi-forum] cancel in standard

[Balaji, Pavan]

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