I am still studying the various proposals but these are some questions
and observations that I have so far encountered in the latest proposal
from Raja and Eric to make GRs persistent.
1. The first question is the one that Rajeev just posted. If I want to
use GRs to implement nonblocking MPI-IO calls, I will have to invent a
mechanism to free the GR(s) that I create, since the user will not know
that the request handle I return is a persistent request handle. The only
one that has come to mind so far is to allocate and reuse a pool of GRs
in MPI_Init, possibly add to the pool if I need more, and free all these
guys when I reach MPI_Finalize.
2. Rajeev's proposal to make GRs nonpersistent means that I can't use
MPI_Start (without redefining it) since it is currently only defined for
persistent requests. This may be ok since there are implications for
hooks in MPI_TEST/WAIT already to support GRs, as well as implications
for the "progress engine" of MPI. But the details need to be hammered
out! (How does the Forum view adding semantics to existing routines?)
3. The simplified version glosses over the details of cancelling a GR,
and of invoking the cancel_fn when an error is returned from any of the
start_fn, advance_fn, or finish_fn. These details in the prior (complex)
proposals seemed to me to be getting the 'state' of the request correct
for subsequent MPI_TEST/WAIT/TEST_CANCELLED invocations--i.e., the state
of a request must be able to return the correct information to the user.
Would the details of interaction be the same under the simplified proposal?
As for whether or not a template model is useful, I have the following
musings. In my opinion, GRs do not fit the model suggested for persistent
requests; they are not invoked repeatedly within inner parallel loops
with the same arguments, at least for implementing MPI-IO functionality.
Instead, GRs are a means for extending the MPI predefined request forms,
in much the same way that users are allowed to extend predefined MPI
Datatypes. That leads to the multiple (complex!) functions that have
been previously proposed, to allow reuse of forms but in separate
instantiations. For now, my mind is keyed to using GRs for implementing
MPI-IO, and a simpler version *may* suffice for that, but this short-
sightedness disallows other uses not yet dreamt of in my poor philosophy.
So it seems we must decide if we want extensible request types, and if so,
proceed as we were before (with as many simplifications as possible!). If
we don't want extensible request types, then it is reasonable to overload
existing functions with new semantics.
Linda
lstanberry@llnl.gov