> Date: Wed, 12 Jun 1996 08:05:39 -0500
> From: Steve Huss-Lederman <lederman@cs.wisc.edu>
> This is not my understanding of what the Forum voted for. They voted
> to send handlers to a chapter on threads. Thus, handlers may only be
> required on systems with threads. This does limit their use in GR so
> I think the proposal below is interesting.
I am sorry for my imprecise expression. Maybe we could have
generalized requests useful both when there are handlers and when not.
> It seems as if the proceed function only gets called when a
> test/wait is called. It seems to me that progress on the GR is only
> made once a wait/test is called.
Basically, that is true and inherent with this proposal. Its compliance
to MPI-1 type progress rule is in doubt, but I think that is not much
different from the situation around SEND/RECV.
There can be some progress before a WAIT/TEST is called, as
start_fn can start as many operations as it wants.
In some cases, that is all a GR wants to perform.
In other cases, however, a GR's operation needs to be broken down into
phases. In fact, the ALLGATHER example in the current draft tries to
repeatedly shifts data, and each shifting has to complete before the
next shifting starts. In cases like this, the GR's operation
completes only when WAIT/TEST is called.
I am not sure what to do when a GR is freed before it completes.
Probably I would register the GR to an internal queue and will
poll/proceed it whenever I have a chance (such as in MPI_Finalize).
> Also, can only 1 request go on at a time? The current proposal
> allows multiple ones.
Surely more than one requests can be started at a time. The
proceed_fn in my last mail only allows you to TEST/WAIT them only one
at a time. A proceed_fn could be defined to return an array_of_requests.
int proceed_fn(MPI_Request request,
int incount,
MPI_Request *subrequest,
int *outcount,
MPI_Request *new_subrequest)
Here it seems outcount has to be INOUT, and it is an implementation
that supplies an upper bound of the number of new_subrequest.
> Thus, does wait hang up until all the proceeds finish? This may
> depend on actions at other processes so it could be a long delay.
> If this is the case, then it does not seem to allow overlap of the
> GR with other work. Along the same lines, test seems as if it can
> get hung up in the proceed. This would seem to violate the
> difference between test and wait.
A proceed_fn itself should not TEST/WAIT on any request; it
may start operations and/or free requests. I think, however, heavy
operations like local blocking IO should be allowed in a proceed_fn.
> Thus, there is 1 status for all the subrequests that occur from the
> proceed(s) call(s). Status is mostly an opaque object. Where does
> the info get placed in status? How does the proceed fn know where it
> can write and what if it wants to place lots of info. It cannot
> control the size of status.
I think the status returned by the outer (generalized) WAIT should
basically talk only about the status of the generalized request as a
whole.
> In the current proposal this type of info might get put into
> extra_state. Is that that is intended? If not, how is status being
> exposed?
Yes. Users can check the value of status in various callback functions
and copy any information they think necessary into extra_state, which
they can define as they wish.
On the other hand, as suggested in a "Missing" in the original GR
proposal (line 36 p162), it would be good to add to MPI_Status a new
field which will contain a pointer to a GR specific status.
Koichi Konishi konishi@research.nj.nec.com
NEC Research Institute Office: 609-951-2628
FAX: 609-951-2488