[Mpi-forum] cancel in standard

[Supalov, Alexander]

Just a note: MPI_Cancel would be next to MPI_ANY SOURCE to go had one introduced assertions. :)

-----Original Message-----
From: mpi-forum [mailto:mpi-forum-bounces at lists.mpi-forum.org] On Behalf Of William Gropp
Sent: Thursday, June 4, 2015 2:24 PM
To: Main MPI Forum mailing list
Subject: Re: [Mpi-forum] cancel in standard

But the user did care about it, and they decided to cancel it.  It may not be one message, but one per iteration.  And the semantics is clear (even if the standard's language isn't).

Bill

On Jun 3, 2015, at 10:08 PM, Jeff Hammond <jeff.science at gmail.com> wrote:

> What's the harm in letting a message that the user clearly does not 
> care about sit in a queue/buffer forever?  I consider this an 
> acceptable consequence of a really stupid feature.
> 
> Jeff
> 
> On Wed, Jun 3, 2015 at 9:50 PM, William Gropp <wgropp at illinois.edu> wrote:
>> Pavan is correct about the intent, and we could make this more precise.  The basic requirement is that a message is *guaranteed* to either be canceled (on send) or received.  Sitting in a queue or buffer somewhere does not count.
>> 
>> Bill
>> 
>> On Jun 3, 2015, at 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."
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> _______________________________________________
>>> mpi-forum mailing list
>>> mpi-forum at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>> 
>> _______________________________________________
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> 
> 
> 
> --
> Jeff Hammond
> jeff.science at gmail.com
> http://jeffhammond.github.io/
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

_______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052