>> The problem is not test_fn vs wait_fn. The problem is that a user call to
>> MPI_WAIT may block the MPI process in some implementations and may put it
>> in a polling cycle in other implementations. The user does not know (now)
>> which is which. We would need to specify two possible behaviors for
>> MPI_WAIT, one where the user callback is repeatedly invoked, and one where
>> it is OK to call a blocking callback within MPI_WAIT. We would need to
>> restrict implementations so that it is OK for the user to block in
>> MPI_WAIT. We would need to provide a mechanism fo the user to find out
>> which implemtation is used on the system it runs. It's even uglier at
>> second glance
Rajeev wrote:
> My point was that the user provides a test_fn and a wait_fn and
> doesn't care which function is used by the MPI implementation within
> MPI_Wait. We can specify that it is up to the implementation to decide
> whether to use test_fn or wait_fn, depending on whether it chooses to
> poll or block in MPI_Wait.
> The user need not know which function was used; the only thing he is
> guaranteed is that MPI_Wait will return after the request has
> completed.
And both proposals do not solve the following problem:
Progress on the general request can be achived only by polling on
an interface outside of MPI, and
the application calls e.g. a collective MPI function, and
progress must be done on the generalized request while the MPI
function is executing (otherwise the application e.g. gets a deadlock).
In Marc's proposal I do not see how the polling on the external
interface can be done.
In Rajeev's proposal there is explicitly no way to force MPI
only to use the callback for polling (test_fn).
We have the problem to combine
a MPI progress engine, that can be (not always the same)
- event driven
- polling
- or both
- or chosable
with a generalized-request progress engine, that can be (not always the same)
- event driven
- polling
- or both
- or chosable
("Both" means one has to interfaces with different strategies where
progress can occur, "chosable" means one interface, but the method
can be choosen.)
Marc's, Rajeev's and the LAST-meeting proposal at least fulfil
the following requirements
generalized-request progress engine
event dr. polling both chosable
MPI event driven Marc/Rajeev Marc
polling Marc/LAST Rajeev/LAST LAST Marc/Rajeev/LAST
both Marc Marc
chosable Marc/LAST LAST LAST Marc/LAST
But we should solve the full matrix.
Possibly I did not unterstand Rajeev's proposal correctly and it
fulfils all the requirements. -- Please correct me.
Otherwise we should add the missing parts to Marc's proposal
or combine Marc's with that from the last meeting.
Rolf
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626
Germany rabenseifner@rus.uni-stuttgart.de