The goal of this MPI-2 extension is to allow users to define new nonblocking operations. Such an outstanding nonblocking operation is represented by a (generalized) request. A fundamental property of nonblocking operations is that progress toward the completion of this operation occurs asynchronously, i.e., concurrently with normal program execution. Typically, this requires execution of code concurrently with the execution of the user code, e.g., in a separate thread or in a signal handler. Operating systems provide a variety of mechanisms in support of concurrent execution. MPI does not attempt to standardize or replace these mechanisms: it is assumed programmers who wish to define new asynchronous operations will use the mechanisms provided by the underlying operating system. Thus, the calls in this section only provide a means for defining the effect of MPI calls such as MPI_WAIT or MPI_CANCEL when they apply to generalized requests, and for signaling to MPI the completion of a generalized operation.
Rationale.
It is tempting to also define an MPI standard mechanism for
achieving concurrent execution of
user-defined nonblocking operations.
However, it is very difficult to define such a mechanism without
consideration of the specific mechanisms used in the operating system.
The Forum feels that concurrency mechanisms are a proper part
of the underlying operating system and should not be standardized by
MPI; the MPI standard should only deal with the interaction of
such mechanisms with MPI.
( End of rationale.)
For a regular request, the operation associated with the request is
performed by the MPI implementation, and the operation
completes without intervention by the application. For a generalized
request, the operation associated with the request is performed by the
application; therefore, the application must notify MPI when the
operation completes. This is done by making a call to
MPI_GREQUEST_COMPLETE.
MPI maintains the ``completion'' status of generalized requests. Any
other request state has to be maintained by the user.
A new generalized request is started with
| MPI_GREQUEST_START(query_fn, free_fn, cancel_fn, extra_state, request) | |
| IN query_fn | callback function invoked when request status is queried (function) |
| IN free_fn | callback function invoked when request is freed (function) |
| IN cancel_fn | callback function invoked when request is cancelled (function) |
| IN extra_state | extra state |
| OUT request | generalized request (handle) |
int MPI_Grequest_start(MPI_Grequest_query_function *query_fn, MPI_Grequest_free_function *free_fn, MPI_Grequest_cancel_function *cancel_fn, void *extra_state, MPI_Request *request)
MPI_GREQUEST_START(QUERY_FN, FREE_FN, CANCEL_FN, EXTRA_STATE, REQUEST, IERROR)
INTEGER REQUEST, IERROR
EXTERNAL QUERY_FN, FREE_FN, CANCEL_FN
INTEGER (KIND=MPI_ADDRESS_KIND) EXTRA_STATE
static MPI::Grequest MPI::Grequest::Start(const MPI::Grequest::Query_function query_fn, const MPI::Grequest::Free_function free_fn, const MPI::Grequest::Cancel_function cancel_fn, void *extra_state)
Advice to users.
Note that a generalized request belongs, in C++, to the class
MPI::Grequest, which is a derived class of MPI::Request.
It is of the same type as regular requests, in C and Fortran.
( End of advice to users.)
The call starts a generalized request and returns a handle to it in
request.
The syntax and meaning of the callback functions are listed below. All callback functions are passed the extra_state argument that was associated with the request by the starting call MPI_GREQUEST_START. This can be used to maintain user-defined state for the request. In C, the query function is
typedef int MPI_Grequest_query_function(void *extra_state, MPI_Status *status);
in Fortran
SUBROUTINE GREQUEST_QUERY_FUNCTION(EXTRA_STATE, STATUS, IERROR)
INTEGER STATUS(MPI_STATUS_SIZE), IERROR
INTEGER(KIND=MPI_ADDRESS_KIND) EXTRA_STATE
and in C++
typedef int MPI::Grequest::Query_function(void* extra_state, MPI::Status& status);
query_fn function computes the status that should be returned for the generalized request. The status also includes information about successful/unsuccessful cancellation of the request (result to be returned by MPI_TEST_CANCELLED).
query_fn callback is invoked by the MPI_{WAIT|TEST}{ANY|SOME|ALL} call that completed the generalized request associated with this callback. The callback function is also invoked by calls to MPI_REQUEST_GET_STATUS, if the request is complete when the call occurs. In both cases, the callback is passed a reference to the corresponding status variable passed by the user to the MPI call; the status set by the callback function is returned by the MPI call. If the user provided MPI_STATUS_IGNORE or MPI_STATUSES_IGNORE to the MPI function that causes query_fn to be called, then MPI will pass a valid status object to query_fn, and this status will be ignored upon return of the callback function. Note that query_fn is invoked only after MPI_GREQUEST_COMPLETE is called on the request; it may be invoked several times for the same generalized request, e.g., if the user calls MPI_REQUEST_GET_STATUS several times for this request. Note also that a call to MPI_{WAIT|TEST}{SOME|ALL} may cause multiple invocations of query_fn callback functions, one for each generalized request that is completed by the MPI call. The order of these invocations is not specified by MPI.
In C, the free function is
typedef int MPI_Grequest_free_function(void *extra_state);
and in Fortran
SUBROUTINE GREQUEST_FREE_FUNCTION(EXTRA_STATE, IERROR)
INTEGER IERROR
INTEGER(KIND=MPI_ADDRESS_KIND) EXTRA_STATE
and in C++
typedef int MPI::Grequest::Free_function(void* extra_state);
free_fn function is invoked to clean up user-allocated resources when the generalized request is freed.
free_fn callback is invoked by the MPI_{WAIT|TEST}{ANY|SOME|ALL} call that completed the generalized request associated with this callback. free_fn is invoked after the call to query_fn for the same request. However, if the MPI call completed multiple generalized requests, the order in which free_fn callback functions are invoked is not specified by MPI.
free_fn callback is also invoked for generalized requests that are freed by a call to MPI_REQUEST_FREE (no call to WAIT_{WAIT|TEST}{ANY|SOME|ALL} will occur for such a request). In this case, the callback function will be called either in the MPI call MPI_REQUEST_FREE(request), or in the MPI call MPI_GREQUEST_COMPLETE(request), whichever happens last. I.e., in this case the actual freeing code is executed as soon as both calls MPI_REQUEST_FREE and MPI_GREQUEST_COMPLETE have occurred. The request is not deallocated until after free_fn completes. Note that free_fn will be invoked only once per request by a correct program.
Advice to users.
Calling MPI_REQUEST_FREE(request) will cause the
request handle to be set to MPI_REQUEST_NULL.
This handle to the generalized request is no longer valid. However,
user copies of this handle are valid until after
free_fn completes since MPI does not deallocate the object
until then. Since free_fn is not
called until after MPI_GREQUEST_COMPLETE, the user copy of
the handle can be used to make this call. Users should note that
MPI will deallocate the object after free_fn
executes. At this point, user copies of the request handle no
longer point to a valid request. MPI will not set user copies to
MPI_REQUEST_NULL in this case, so it is up to the user to
avoid accessing this stale handle. This is a special case where MPI
defers deallocating the object until a later time that is known by
the user.
( End of advice to users.)
In C, the cancel function is
typedef int MPI_Grequest_cancel_function(void *extra_state, int complete);
in Fortran
SUBROUTINE GREQUEST_CANCEL_FUNCTION(EXTRA_STATE, COMPLETE, IERROR)
INTEGER IERROR
INTEGER(KIND=MPI_ADDRESS_KIND) EXTRA_STATE
LOGICAL COMPLETE
and in C++
typedef int MPI::Grequest::Cancel_function(void* extra_state, bool complete);
cancel_fn function is invoked to start the cancelation of a generalized request. It is called by MPI_REQUEST_CANCEL(request). MPI passes to the callback function complete=true if MPI_GREQUEST_COMPLETE was already called on the request, and complete=false otherwise.
All callback functions return an error code. The code is passed back and dealt with as appropriate for the error code by the MPI function that invoked the callback function. For example, if error codes are returned then the error code returned by the callback function will be returned by the MPI function that invoked the callback function. In the case of MPI_{WAIT|TEST}{ANY} call that invokes both query_fn and free_fn, the MPI call will return the error code returned by the last callback, namely free_fn. If one or more of the requests in a call to MPI_{WAIT|TEST}{SOME|ALL} failed, then the MPI call will return MPI_ERR_IN_STATUS. In such a case, if the MPI call was passed an array of statuses, then MPI will return in each of the statuses that correspond to a completed generalized request the error code returned by the corresponding invocation of its free_fn callback function. However, if the MPI function was passed MPI_STATUSES_IGNORE, then the individual error codes returned by each callback functions will be lost.
Advice to users.
query_fn must not set the error field of
status
since query_fn may be called by MPI_WAIT or
MPI_TEST, in which case the error field of status
should not change. The MPI library knows the ``context'' in which
query_fn is invoked and can decide correctly when to put
in the error field of status the returned error code.
( End of advice to users.)
| MPI_GREQUEST_COMPLETE(request) | |
| INOUT request | generalized request (handle) |
int MPI_Grequest_complete(MPI_Request request)
MPI_GREQUEST_COMPLETE(REQUEST, IERROR)
INTEGER REQUEST, IERROR
void MPI::Grequest::Complete()
The call informs MPI that the operations represented by the generalized request request are complete. (See definitions in Section Semantic Terms .) A call to MPI_WAIT(request, status) will return and a call to MPI_TEST(request, flag, status) will return flag=true only after a call to MPI_GREQUEST_COMPLETE has declared that these operations are complete.
MPI imposes no restrictions on the code executed by the callback functions. However, new nonblocking operations should be defined so that the general semantic rules about MPI calls such as MPI_TEST, MPI_REQUEST_FREE, or MPI_CANCEL still hold. For example, all these calls are supposed to be local and nonblocking. Therefore, the callback functions query_fn, free_fn, or cancel_fn should invoke blocking MPI communication calls only if the context is such that these calls are guaranteed to return in finite time. Once MPI_CANCEL is invoked, the cancelled operation should complete in finite time, irrespective of the state of other processes (the operation has acquired ``local'' semantics). It should either succeed, or fail without side-effects. The user should guarantee these same properties for newly defined operations.
Advice
to implementors.
A call to MPI_GREQUEST_COMPLETE may unblock a blocked user
process/thread. The MPI library should ensure that the blocked user
computation will resume.
( End of advice to implementors.)