<div style="font-family: Helvetica; font-size: 13px; ">I might be reading this differently then everyone else, but it appears that you're asking which SEND would be matched, not which RECEIVE. Assuming you use the same communicator, tag, and recipient, messages in MPI are always guaranteed to be in order. So if you manage to cancel the Irecv in time, you'll receive the first send in the Recv and the second send will be waiting to be matched. There isn't a situation where you'd receive message number 2 before message number 1 or not receive message 1 at all.<div><br></div><div>Wesley</div></div>
<div></div>
<p style="color: #A0A0A8;">On Wednesday, August 7, 2013 at 7:16 PM, Matthieu Dorier wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>Ah great, thanks!</div><div><br></div><div>Matthieu</div><div><br></div><div>----- Mail original -----</div><blockquote type="cite"><div><div>De: "Rajeev Thakur" <<a href="mailto:thakur@mcs.anl.gov">thakur@mcs.anl.gov</a>></div><div>À: <a href="mailto:discuss@mpich.org">discuss@mpich.org</a></div><div>Envoyé: Mercredi 7 Août 2013 16:34:18</div><div>Objet: Re: [mpich-discuss] Semantics of MPI_Cancel</div><div><br></div><div>MPI_Cancel will succeed only if the receive can be canceled, i.e.,</div><div>not part of the message has already been received into the receive</div><div>buffer. So, if the cancel succeeds, the send will match the next</div><div>receive. You have to check the error code returned by cancel.</div><div><br></div><div>On Aug 7, 2013, at 4:18 PM, Matthieu Dorier wrote:</div><div><br></div><blockquote type="cite"><div><div>So either there is no way to know which MPI_Send will be matched,</div><div>since even with</div><div>MPI_Irecv(req); MPI_Test(flag,req); if(!flag) {MPI_Cancel(req)}</div><div>MPI_Recv()</div><div>the MPI_Irecv could have completed between the MPI_Test and the</div><div>MPI_Cancel...</div><div><br></div><div>Or does the content of the MPI_Irecv, which is supposed to have</div><div>been put in the user-provided buffer, gets transferred into the</div><div>buffer of the next MPI_Recv upon cancellation of the MPI_Irecv?</div><div><br></div><div>Thanks,</div><div><br></div><div>Matthieu</div><div><br></div><div>----- Mail original -----</div><blockquote type="cite"><div><div>De: "Rajeev Thakur" <<a href="mailto:thakur@mcs.anl.gov">thakur@mcs.anl.gov</a>></div><div>À: <a href="mailto:discuss@mpich.org">discuss@mpich.org</a></div><div>Envoyé: Mercredi 7 Août 2013 16:10:02</div><div>Objet: Re: [mpich-discuss] Semantics of MPI_Cancel</div><div><br></div><div>You canceled the recv, not the send. The send will still go</div><div>through</div><div>and match the first available receive that can be matched.</div><div><br></div><div>On Aug 7, 2013, at 3:25 PM, Matthieu Dorier wrote:</div><div><br></div><blockquote type="cite"><div><div>Hi,</div><div><br></div><div>Suppose process 0 does the following</div><div>MPI_Irecv(...req)</div><div>MPI_Cancel(req)</div><div>MPI_Recv</div><div><br></div><div>and process 1 does</div><div>MPI_Send</div><div>MPI_Send</div><div><br></div><div>Does process 0 receives the data from the first or the second</div><div>MPI_Send?</div><div>(I'd tend to say the second, but I'd like a confirmation).</div><div><br></div><div>Thanks!</div><div><br></div><div>Matthieu Dorier</div><div>PhD student at ENS Cachan Brittany and IRISA</div><div><a href="http://people.irisa.fr/Matthieu.Dorier">http://people.irisa.fr/Matthieu.Dorier</a></div><div>_______________________________________________</div><div>discuss mailing list <a href="mailto:discuss@mpich.org">discuss@mpich.org</a></div><div>To manage subscription options or unsubscribe:</div><div><a href="https://lists.mpich.org/mailman/listinfo/discuss">https://lists.mpich.org/mailman/listinfo/discuss</a></div></div></blockquote><div><br></div><div>_______________________________________________</div><div>discuss mailing list <a href="mailto:discuss@mpich.org">discuss@mpich.org</a></div><div>To manage subscription options or unsubscribe:</div><div><a href="https://lists.mpich.org/mailman/listinfo/discuss">https://lists.mpich.org/mailman/listinfo/discuss</a></div></div></blockquote><div>_______________________________________________</div><div>discuss mailing list <a href="mailto:discuss@mpich.org">discuss@mpich.org</a></div><div>To manage subscription options or unsubscribe:</div><div><a href="https://lists.mpich.org/mailman/listinfo/discuss">https://lists.mpich.org/mailman/listinfo/discuss</a></div></div></blockquote><div><br></div><div>_______________________________________________</div><div>discuss mailing list <a href="mailto:discuss@mpich.org">discuss@mpich.org</a></div><div>To manage subscription options or unsubscribe:</div><div><a href="https://lists.mpich.org/mailman/listinfo/discuss">https://lists.mpich.org/mailman/listinfo/discuss</a></div></div></blockquote><div>_______________________________________________</div><div>discuss mailing list <a href="mailto:discuss@mpich.org">discuss@mpich.org</a></div><div>To manage subscription options or unsubscribe:</div><div><a href="https://lists.mpich.org/mailman/listinfo/discuss">https://lists.mpich.org/mailman/listinfo/discuss</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>