<html><body>
<p>The semantic provided by using MPI_REQUEST_FREE on an active send request is clearly useful and is clearly mandated by MPI 1.1. It seems to have been a mistake to assume it would always be practical to support this symantic in MPI implementations and we can discuss removing the guarentee or making it optional via MPI_INIT time assertion. I do not see how we can suggest the intent was ever vague.<br>
<br>
USEFULNESS:<br>
<br>
The semantic is useful for what amounts to a home rolled get. Say all tasks know that at some point in each step they may need to provide data to other tasks. They do not know what tasks will want which data so they post an IRECV for any incoming data pull commands and TEST or they do IPROBEs and post RECVs when it comes time to accept data pulls. Each RECVed message at a get target represents some remote task describing the data it wants. The task that sent the data pull command (the get origin) posts a receive suitable for the data it requested. The data cannot be sent from the get target until the RECV of the pull command is complete so once the get origin completes the RECV of the data it requested<b> it can be sure</b> the current content of the send buffer with the pull command is obsolete.<br>
<br>
By immediately after MPI_ISEND, using MPI_REQUEST_FREE on the request handle from the data pull command, the application is spared the need to keep track of that handle until after the data comes in. Immediately calling MPI_WAIT on the ISEND is safe and removes the need to keep track of the handle but delays the application. Saving the request handle to call MPI_WAIT after the pulled data comes in will give good performance because by the time the data has come in the MPI_WAIT should normally be very fast. It does require keeping track of all data pull handles though. <br>
<br>
There is no magic in reaching a conclusion at the get side that receiving the pulled data means the content of the data pull command buffer is no longer needed. The problem is that the arrival of the reply may not always guarantee that other attributes of the buffer status are complete.<br>
<br>
MPI 1.1 statement:<br>
<br>
<font size="4">[]</font><i><font size="4"> Advice to users.</font></i><font size="4"> </font>
<p><font size="4">Once a request is freed by a call to MPI_REQUEST_FREE, it is not possible to check for the successful completion of the associated communication with calls to MPI_WAIT or MPI_TEST. Also, if an error occurs subsequently during the communication, an error code cannot be returned to the user --- such an error must be treated as fatal. Questions arise as to how one knows when the operations have completed when using MPI_REQUEST_FREE. Depending on the program logic, there may be other ways in which the program knows that certain operations have completed and this makes usage of MPI_REQUEST_FREE practical. For example, an active send request could be freed when the logic of the program is such that the receiver sends a reply to the message sent --- the arrival of the reply informs the sender that the send has completed and the send buffer can be reused. An active receive request should never be freed as the receiver will have no way to verify that the receive has completed and the receive buffer can be reused. (</font><i><font size="4"> End of advice to users.</font></i><font size="4">) </font>
<p> Dick
<p><br>
<br>
<br>
Dick Treumann - MPI Team/TCEM <br>
IBM Systems & Technology Group<br>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
</body></html>