Re: One more thought on 1sided

(no name) (j_nieplocha@pnl.gov)
Wed, 22 Nov 1995 10:27:28 -0800

In message <9511221749.AA21134@tbag.osc.edu>Greg Burns writes:
> 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)

The hardware that supports interrupts includes: IBM SP, Paragon, Delta,
IPSC/860, and CM-5

> 2 - timer poll (MPICH, IBM)
> 3 - poll during MPI_ functions (LAM)
>
> 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.

Well, calling an MPI function by remote process to assure progress is a
SPECIFIC ACTION. This requirement imposed on the MPI-2 applications is against
the principles of 1-sided communication.

I fully support LLoyd's proposal. And, if some platform or implementation cannot
support truly 1-sided comms it should be stated clearly so that the applications
are not fooled. MPI-2 functionality is supposed to be optional, isn't ?

Jarek Nieplocha