The latest proposal from Marc is, IMHO, anything but generalized. It is
so loaded with exceptions and restrictions that at best I think it may
be suitable to some specialized, uninteresting (to this user), internal
work, and too intimimidating to most users to be very popular. Of course,
I think the same about obscure corners of other specs, so I guess I just
don't understand the mindset of those designing them. I don't mean to
offend anyone by my misgivings about the utility of the proposal: it is
most likely that I just don't understand it well enough to appreciate its
brilliance.
When I first read the GR proposals of the past, I really thought they were
elegant and gave users some powerful tools for building multi-faceted
(synchronous or asynchronous) requests of their own, extending MPI ops for
their own environments. The current proposal seems much weaker and requires
extensive effort on the part of the user to construct useful GRs, or at
least that was how it seemed to me.
I risk being offensive by asking again what is the goal of providing a GR
facility? If it is to allow users to construct, in general, a new set of
MPI operations, and get access to these through the existent MPI_REQUEST
type (handle), then I very much dislike putting the restrictions on the
callback functions and the (trigger) arguments to these functions as
currently described. That is, a GR and its component idioms should appear
to a user as any other MPI constructs, as much as possible. But I'm
rambling...
When I asked this question the last time, I was a bit stunned to hear
that the motivation (at least from Eric) for GRs was to expose the
'progress engine' of MPI, and make it accessible to the user. That was
sort of the inside-out view of what I had always thought GRs were about.
At your last meeting, I gather that trying to expose the progress engine,
or to put requirements on it such as causing it to invoke a push_fn, was
deemed untenable. I'm not sure of all the arguments here, but I assume
that is why the newer proposals try to back off to specifying invocations
of a progress/push function only at clearly-defined MPI events, which is
equivalent to posting a progress_fn to an MPI request (as in 7.9.4 of the
1/15/97 draft).
However, the newest proposal also wants to allow the user to invoke the
progress_fn for some user-defined event, and this is done by calling
MPI_GR_KICK. That is, instead of MPI being responsible for periodically
calling the progress_fn, the user is responsible for this.
Why not fix the (1/15/97) GR proposal so that the push_fn (progress_fn) is
invoked appropriately by the user, instead of requiring the internals of
MPI to "repeatedly" do this for the user? Then the user is responsible,
for example, for determining if this is done by polling or selecting.
Would this solve the objections to the earlier proposal?
Or am I hopelessly missing the point again?
Linda
lstanberry@llnl.gov
===========================================================================
Further comments/questions on the newest proposal:
Questions:
(1) Why do we need to duplicate the posted-handler functionality in GRs?
(2) Why not have the user invoke the progress function (which the user
provides) directly instead of calling MPI_GR_KICK? Is it because the
MPI_GR_KICK also needs to mark the GR as complete when the progress_fn
returns true? Since the user writes the progress_fn, marking the request
as complete can't happen in this function; it needs to happen in MPI
itself. It currently isn't specified when/where this happens.
Here's some specifics that I think are problematic:
* Mixing trigger-ed and NULL-trigger-ed events in one paradigm is not
desirable. The triggers can be implemented by handlers (I think Steve
pointed this out). Having to use MPI_NULL_TRIGGER when I don't want
this (e.g., user-driven events) is awkward.
* Triggers are requests that are heavily restricted (can't be used in
MPI_WAIT/TEST/...) and it is undesirable to call them MPI_REQUESTs if you
want to do this. (BTW, can a trigger be a GR?)
* "Chaining" is awkward and doesn't allow asynchronous (simultaneous)
events...without also requiring GRs as wrapping for nested MPI_REQUESTS,
and that doesn't extend well...I have to have a GR for each component MPI
event of a new operation possibly defined in terms of other arbitrary MPI
events, including GRs? Bleaah! I think this is a big step backwards.
* Since triggers invoke the progress_fn without the GR with which this
progress_fn is associated as an argument, the implication is that the
extra state arg has to contain the GR handle. Since the user defines
the extra state, this gives the user too much opportunity to lose the
GR info. This doesn't seem reasonable to me, but then I misplace things
a lot.
* The mixing of two paradigms caused awkward specifications for the
complete_fn as well. (In short, the rules for the mixture is beginning
to look like something the IRS publishes :-) I doubt that I will be able
to remember all that I will need to use this model correctly, so I'll
probably get audited...er, deadlocked.