<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">That’s one of the reasons for the various tickets to address the send-cancel description. However, note that if the cancel fails, then the communication is not marked for cancellation, and an MPI_Wait could then wait until the message is received. The intent was this:<div><br></div><div>P0 sends a message. Message arrives at P1 and and is processed by the MPI runtime, but the user code hasn’t matched it (e.g., message is placed in the unexpected message queue).</div><div><br></div><div>P0 attempts to cancel the message. This causes a cancel request to be sent to P1. If the message is in the unexpected queue, and hasn’t been matched by any user MPI call (recv, mprobe, or iprobe), then the message is removed from the unexpected message queue, and a ack is sent from P1 to P0 that the message was successfully canceled. Otherwise, P1 sends a nack to P0, saying that it was unable to cancel the message. Note that this requires the MPI runtime to track which unexpected messages have been “observed”. See below.</div><div><br></div><div>However, the MPI standard doesn’t have an unexpected message queue concept; that is a (nearly universal) implementation detail. If we retain cancel of sends (for which there are very few but unfortunately not zero uses), we’ll need to update the text to clearly define the behavior without referring to implementation approaches (except as an advice to implementors). It is further complicated by the MPI_T interface - what if a performance variable is queried about the number of messages in the unexpected queue? Does that count as an observation of the message? </div><div><div><br></div><div>Bill</div><div><br><div>
William Gropp<br>Director, Parallel Computing Institute<br>Thomas M. Siebel Chair in Computer Science<br>Chief Scientist, NCSA<br>University of Illinois Urbana-Champaign<br><br><br><br><br>
</div>
<br><div><div>On Nov 1, 2015, at 11:59 AM, Marek Tomáštík <<a href="mailto:tomastik.marek@gmail.com">tomastik.marek@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div><div>2015-10-31 17:33 GMT+01:00 William Gropp <span dir="ltr"><<a href="mailto:wgropp@illinois.edu" target="_blank">wgropp@illinois.edu</a>></span>:<br>>Under
the interpretation of using whether the target process has observed,<br>>rather than received the message, a consistent interpretation is that
the<br>>MPI_Cancel fails at the source, as it would if the message had been
received.<br><br></div>But does that satisfy the requirement that "[i]f a communication is marked for cancellation, then a MPI_WAIT call for that communication is guaranteed to return, irrespective of the activities of other processes (i.e., MPI_WAIT behaves as a local function); similarly if MPI_TEST is repeatedly called in a busy wait loop for a cancelled communication, then MPI_TEST will eventually be successful"? As far as I can see, MPI_Wait for the matched send cannot be local, since it can complete only once the receiver actually receives the message.<br><br></div>I understand that cancelling of sends is in the process of being phased out of the standard, but I would like to find out how/if it's possible to implement this feature correctly given that it is, currently, a part of the standard.<br><div><br></div><div>Marek Tomáštík<br></div></div>
_______________________________________________<br>mpi-forum mailing list<br><a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a><br>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</blockquote></div><br></div></div></body></html>