[Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues

[Richard Treumann]

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.

USEFULNESS:

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 it can be sure the
current content of the send buffer with the pull command is obsolete.

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.

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.

MPI 1.1 statement:

[] Advice to users.

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. ( End of advice
to users.)

                  Dick

Dick Treumann  -  MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363





* 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080718/9a14b4f6/attachment.html>