Structure of MPI_Request


Up: Special Considerations Next: Freed Requests Previous: Special Considerations

The MPI_Request object is used for many purposes. The most obvious are the send and receive requests; internally, these are identified as requests with type MPIR_SEND and MPIR_RECV. MPI also has persistent communication operations; these look like sends and receives, but are actually different from an implemenation perspective. For example, a persistent send request needs to hold all of the data needed to start a send operation. This data is not needed as part of the request for other operations. The overloading of the request object is unfortunate, but we can reduce the confusion by putting the data needed by MPI_Start and MPI_Startall for persistent operations together and make it valid only for persistent requests. For this reason, there are two handle types: MPIR_PERSISTENT_SEND and MPIR_PERSISTENT_RECV. These are used to eliminate the separate check on whether the request is persistent. If generalized requests are added to MPI (MPICH already has some hooks for support for these), these two additional forms will be a small added complexity by comparison.

Persistent requests also require that additional information be saved. Since a persistent receive request may have wild-card fields (e.g., tag = MPI_ANY_TAG), these need to be preserved for the next use of the persistent request.

Another common problem is that an MPI_Request is used to represent an operation, such as a nonblocking send, at several different stages of completion. Thus, the state of the operation must be encoded within the request. In ADI-1, this was stored in completer. This value is no longer used; the sample implementation (see mpid/ch2/req.h) uses pointers to functions in the request to indicate what routine to call to test or wait on a request; this pointer is changed depending on what needs to be done. Other implementations may want to use the completer approach.

Finally, it seems natural, at least in a receive request, to have an MPI_Status within the request itself, rather than separate fields. This approach simplifies moving data from the request to the MPI_status.



Up: Special Considerations Next: Freed Requests Previous: Special Considerations