>> 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
What's your point? All machines have interrupt capabilities? OK.
My point is that insisting upon and handling interrupts is a big
constraint on implementors in a variety of circumstances: bare
iron, OS on the side but MPI talking to device directly, OS in the middle
and presenting/hiding the interrupts in some way. This will
not promote a wide variety of healthy, whole and compliant MPI
implementations.
If MPI on any of these machines actually handles progress by interrupting
the application's CPU, I would like to make a note of it.
> 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.
Well, waiting for my next breath is a specific action, but one that will
satisfy most applications. Exactly where is your application going to
break on a polled implementation? We're not talking about realtime MPI, yet.
-- Greg