Re: proposal of Thakur

Rajeev Thakur (thakur@mcs.anl.gov)
Mon, 3 Feb 1997 14:22:45 -0600

> From: Rabenseifner@RUS.Uni-Stuttgart.DE (Rolf Rabenseifner)
> Date: Mon, 3 Feb 1997 19:17:21 +0100 (MEZ)
>
> 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 previous proposals there was a push_fn for progressing
external events. But that was thought to be inefficient.

Therefore, in Marc's current proposal, progress on events external to
MPI is the user's responsibility.

> In Rajeev's proposal there is explicitly no way to force MPI
> only to use the callback for polling (test_fn).

My proposal is a slight modification to Marc's to provide user
specified test/wait functions to determine the completion of an
external event, not to cause progress. It is useful when the external
event has its own progress engine (e.g. file system).
If the user provides a non-null
test/wait function, the MPI implementation must call either one of
those within MPI_Test/MPI_Wait before it checks to see whether
MPI_GR_Complete has been called. In other words, the test_fn/wait_fn
could detect completion and call MPI_GR_Complete.
This allows the user to check for completion of external event,
and not rely only on asynchronous notification via threads or signal
handlers.

> 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.

The above table can only be filled if we provide support for progress
on external events, which is a separate debate on its own.

Rajeev