> If we follow the design currently outlined in the alternative proposal, then
> Process C needs to execute a synchronization involving its window before it
> can load X. Neither of your two examples are guaranteed to work.
I hope that those who originally voted for the third-party communication
fully understand this example so that they know what they will not get from
the vote.
If I understand correctly, the examples I provided might fail not only in the
alternative proposal, but the original proposal, and likely any other proposal
that will surface. Ensuring that they would not fail would probably slow down
message-passing on some architectures.
> This has been discussed at length. Burns argues that we do not care about
> infinite loops, and in any terminating program there must be an MPI call
> executed by each process eventually, namely MPI_FINALIZE. I would argue
> that the semantics need be defined so that infinit programs work OK and,
> therefore, an agent is needed to enforce progress in send-receive. The IBM
> implementation supports a polling mode where incoming messages are dealt
> with only when the receiver executes some MPI call, but even in polling
> mode, an MPI agent is periodically invoked by a timer to ensure progress.
I'm glad I asked. Your answer came as I was preparing a questionnaire to
comp.parallel.mpi to ask implementors whether their MPI handled the infinite
loop case.
My current "P/G/O" proposal presents 1-sided communication in the same light.
Specifically, "third-party" communication (which I call "progressive") is that
which takes the strict interpretation -- i.e. in which a GET or PUT is
guaranteed to complete whether or not the matching operation in the target
(OFFERP in this case) completes. The standard "easy-to-implement" 1-sided
communication (which I call "non-progressive") takes the weaker
interpretation, where a PUT or GET will not necessarily complete unless the
matching operation in the target (OFFER in this case) completes. Both are
provided in the proposal.
-Dave
===============================================================================
David C. DiNucci | MRJ, Inc., Rsrch Scntst |USMail: NASA Ames Rsrch Ctr
dinucci@nas.nasa.gov| NAS (Num. Aerospace Sim.)| M/S T27A-2
(415)604-4430 | Parallel Tools Group | Moffett Field, CA 94035