Marc Snir
02/02/97 05:30 PM
To: thakur @ mcs.anl.gov
cc:
Subject: Re: proposal of Thakur
> Now, I udnerstand how this works if the user calls MPI_TEST repeadely,
> until the request has completed. How does this proposal work if the
user, > insted, decided to call MPI_Wait? Since there is no external
handler that > "pokes" MPI when the I/O completes we need, internally, to
continue polling > and calling the test function.
> Now, some implementations of MPI may have interrupt-driven message
passing, > in which case a process may be descheduled when it executes
MPI_WAIT.
> There is no need for periodic polling, since interrupts from the device
> driver will wake-up the MPI process if progress is required. Such
> implementations will not support the polling behavior. The alternative
> choice is that, when MPI_WAIT is called, a callback function blocks,
> internally until the I/O completes. But some other MPI implementations
of > MPI may poll while the MPI process is blocked on an MPI_WAIT, and may
need > this polling to make progress and avoid deadlocks. These
implementations > will block if the user callback blocks.
I think the solution to this is to provide two callback functions:
a test_fn that doesn't block and a wait_fn that blocks. The
restriction for the user is that if she provides a non-null test_fn,
she must provide a non-null wait_fn and vice-versa. The implementation
is free to use either the test_fn or wait_fn within the MPI_Wait
depending on how it implements MPI_Wait.
Providing these two functions may look ugly at first glance, but it
gives users (like me) a chance to use generalized requests right away
without compulsorily using threads or signal handlers.
Rajeev
***********
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
Marc
***********