On Mon, 10 Jun 1996, Koichi Konishi wrote:
> Date: Mon, 10 Jun 1996 23:06:07 EDT
> From: Koichi Konishi <konishi@research.nj.nec.com>
> To: mpi-external@mcs.anl.gov
> Subject: generalized requests without communication handlers
>
> Generalized requests are up in the air, or about to crash on the
> ground. They are considered to be not much of use unless combined
> with communication handlers, which have been voted out.
>
> 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
>
>
Anthony Skjellum, PhD, Asst. Professor of Computer Science;
Mississippi State University, Department of Computer Science & NSF ERC
Butler, Rm 300, PO Box 9637, Corner of Perry&Barr, Mississippi State,MS 39762
(601)325-8435 FAX: (601)325-8997; http://www.erc.msstate.edu/~tony; Quote:
"What a rain of ashes falls on him that sees the new and cannot leave the
old."-Shakespeare ; e-mail: tony@cs.msstate.edu; Try MPI!