June 2015 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] cancel in standard
by Jeff Hammond 03 Jun '15

03 Jun '15

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(a)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(a)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(a)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(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [Mpi-forum] [MPI Forum] #324: Clarify MPI_ERRORS_ARE_FATAL scope of abort
by Bland, Wesley 03 Jun '15

03 Jun '15

The last two comments are fine, but I have a problem with the first one. Error codes are only useful if you're still in an application to decode them. If you're aborting, the thing provided to abort should be provided to the user in the form of a return code. That's not useful since it can't be turned into a string, class, etc. anymore. > On Jun 3, 2015, at 6:06 PM, MPI Forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > #324: Clarify MPI_ERRORS_ARE_FATAL scope of abort > -------------------------------------+------------------------------------- > Reporter: jjhursey | Owner: wbland > Type: Enhancements to standard | Status: assigned > Priority: Forum feedback requested | Milestone: 2015/12/07 > Version: MPI <next> | California, USA > Keywords: | Resolution: > | Implementation status: Waiting > -------------------------------------+------------------------------------- > > Comment (by bouteill): > > page 342 line 40: when the handler aborts processes, the implementation > should try to provide an error code which is meaningful for the user, as > an example, an error code that can be passed to MPI_ERROR_STRING. > > Rationale for the change: easier to read, all error classes are their own > error codes, and returning error codes can be more precise. There is no > limit on the number of error classes either (MPI_ADD_ERROR_CLASS!) > > > page 377 line 34: is ---the same as--- the default error handler (remove > "the same as") > > page 454: Add before the new text: "By default, the predefined error > handler for windows handles is MPI_ERRORS_ARE_FATAL". (adapted from FILE > chapter wording). Otherwise the default handler on MPI_WIN_NULL is not > defined. > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/324#comment:17> > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum

1 0

Re: [Mpi-forum] cancel in standard
by William Gropp 03 Jun '15

03 Jun '15

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(a)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(a)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(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] cancel in standard
by Sur, Sayantan 03 Jun '15

03 Jun '15

Agreed. On 6/3/15, 8:18 PM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: > >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(a)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(a)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(a)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(a)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(a)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." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>

1 0

Re: [Mpi-forum] cancel in standard
by Balaji, Pavan 03 Jun '15

03 Jun '15

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(a)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(a)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(a)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(a)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(a)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." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >

1 0

Re: [Mpi-forum] cancel in standard
by Sur, Sayantan 03 Jun '15

03 Jun '15

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(a)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(a)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(a)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(a)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." >>>> >>>> >>>> >>>> >>>> >>>> >>

1 0

Re: [Mpi-forum] cancel in standard
by Balaji, Pavan 03 Jun '15

03 Jun '15

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(a)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(a)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(a)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." >>> >>> >>> >>> >>> >>> >

1 0

Re: [Mpi-forum] cancel in standard
by Sur, Sayantan 03 Jun '15

03 Jun '15

+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(a)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(a)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." >> >> >> >> >> >>

1 0

Re: [Mpi-forum] cancel in standard
by Balaji, Pavan 03 Jun '15

03 Jun '15

[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(a)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." > > > > > >

1 0

Slides from the meeting
by Jeff Squyres (jsquyres) 03 Jun '15

03 Jun '15

Don't forget to send me any slides that you presented at the meeting this week. Thanks! -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0