I think generalized requests can be useful even without a help of
communication handlers.
One of the problems you have with the current proposal when you can not
use handlers is you do not know who should call MARK_COMPLETE. But
MARK_COMPLETE need not be called if TEST/WAIT is called with
non-generalized, plain requests, which I assume every generalized
request would usually maintain a few inside.
Take the current proposal and replace a user-supplied
call-back function "mark_complete_fn" with a different type of
call-back function "proceed", which may look like:
typedef int
request_proceed_fn(void *extra_state,
MPI_Request request,
MPI_Request *subrequest,
MPI_Status *status);
This call-back function is invoked by TEST/WAIT to extract
an internally maintained request which TEST/WAIT can block on.
WAIT could be changed like this;
int MPI_Wait(MPI_Request *request, MPI_Status *status)
{
MPI_Request subrequest;
/* if the request is plain, handle it
as we do now */
if (!request->is_general) {
return non_generalized_wait(request, status);
}
/* otherwise, first extract an inner request */
subrequest = MPI_REQUEST_NULL;
request->proceed_fn(request->extra_state,
request,
&subrequest,
status);
/* then repeat calling 'plain wait' and proceed_fn
until the latter returns MPI_COMM_NULL */
while (subrequest != MPI_COMM_NULL) {
MPI_Request newsubreqest;
non_generalized_wait(&subrequest, status);
request->proceed_fn(request->extra_state,
&subrequest, status);
}
return MPI_SUCCESS;
}
Example in section 6.2 can be changed to have a proceed_fn
as follows instead of a handler_fn there:
int proceed_fn(void *extra_state,
MPI_Request *request,
MPI_Status *status)
{
My_Extra *myextra = (MyExtra*)extra_state;
switch (myextra->phase) {
case 1:
*request = myextra->req_recv;
break;
case 2:
MPI_Request_free(request);
*request = myextra->req_send;
break;
case 3:
MPI_Request_free(request);
*request = MPI_Request_null;
/* fill status as you like */
break;
}
return MPI_SUCCESS;
}
I wish I could return more than one internal requests
at once and let WAIT block on them, but that
would make proceed_fn and WAIT look much messier.
The changes above supplies a few of "Missing" items indicated
in this section.
- How can we use status: you can put whatever you
want in status in a call to proceed_fn, which works
like a new callback function suggested in "Missing"
paragraph at line 36 p162.
- There is no complete function in the example:
now there is none in the proposal, either.
I appreciate any comments.
Koichi Konishi konishi@research.nj.nec.com
NEC Research Institute Office: 609-951-2628
FAX: 609-951-2488