Re: One more thought on 1sided

Greg Burns (gdburns@tbag.osc.edu)
Wed, 22 Nov 95 12:49:29 EST

Lloyd says,

>We also need to specify some equivelent to the "progress" rule for
>the one-sided operations. As one of the precepts is to enable applications
>which can perform long periods of computation without having to poll for
>remote communication requests, we want to eliminate implementations which
>delay handling get/put requests from remote nodes until some convenient MPI
>Function is called. I.e, we need to force interrupts, or true shared memory.

Without hardware support your choices for progress are:

1 - interrupt (nobody I know)
2 - timer poll (MPICH, IBM)
3 - poll during MPI_ functions (LAM)

The only diff between 1 and 3 is that a for (;;) application will be
handled. Solution 2 also handles it. Language to "force interrupts"
would have to say this exactly. I think you have some
feeling that 1-sided should happen "right now", but having interrupts
doesn't say anything about time since I can take arbitrarily long to
serve the interrupt. The key element to 1-sided is that it is 1-sided
- no action specific action is required by another MPI process. All of
the 3 possible solutions meet that sufficiently.

As a former kernel engineer, my motto was "half of all evil is caused
by interrupts". I don't enjoy them too much at the POSIX level,
either. I really hope that MPI does not mandate all implementors to
deal with interrupts.

--
Greg