Re: MPI_FINALIZE

[Tony Skjellum <tony@MPI-Softtech.Com>]

Jeff, you are bringing up a meta-question as well as a specific question.
If we are re-examining MPI-2 to make it more usable (performance and
functionality), should we or should we not fix known problems that go
beyond the surface of text errors and small clarifications?  Certainly,
there are such issues.

It appears that the committee can and should consider these either in 2.1,
or in 2.2, given that 2.1 makes more implementations plausible by cleaning
the standard.   No one speaks of a 2.2 here, because it has taken 4 years
for people to get enough over the MPI 2.0 process to even talk about
clarifying it.

At present, our customers want performance as well as functionality.
There are key performance issues in 1-sided, for instance, that we could
raise.  Will they be considered in 2.1?  Consider for instance issues
raised by BSP users about update semantics.  Or what about knowledge of
remote derived data types?  Or about the fact that some existing
implementations point toward higher bandwidth and higher latency than two
sided, instead of the expected lower bandwidth and lower latency.  Perhaps
Rolf Rabenseifner will comment on this.

Consider also the problem of merging multiple groups into a single unified
world.  Comm1 spawns Comm2; then Comm1 spawns Comm3.  It took Rolf
Rabenseifner, Puri Bangalore, and I some significant to work out
reasonable solutions for making one unified communicator.  This speaks to
functionality of the standard.  Also, then consider how you might want to
disconnect these parts without necessarily attention to the original
structure of how they were assembled.  Consider how to merge many
singletons in practice, the case of interest in newer applications of
MPI-2...

Here is another issue.  I don't believe there are persistent generalized
requests, but these are precisely what one wants in some situations.

What about the fact that the MPI_THREAD_INIT() is optional.  That makes it
hard to exploit/handle in an implementation that one is using threads,
since one isn't required to use it...

Even so, I don't think that anyone has signed up for another full-blown
exercise, but rather a clarification process right now.  Nonetheless, one
can do some significant improvements by getting the currently agreed
standard, both in functionality and performance, even consistent with
MPI-2's main emphasis on functionality.  Overall, I think it should wait
for more real implementations, like we all seem to do right now, that work
to the MPI 2.1 standard first.

Tony

Anthony Skjellum, PhD, President (tony@mpi-softtech.com)
MPI Software Technology, Inc., Ste. 33, 101 S. Lafayette, Starkville, MS 39759
+1-(662)320-4300 x15; FAX: +1-(662)320-4301; http://www.mpi-softtech.com
"Best-of-breed Software for Beowulf and Easy-to-Own Commercial Clusters."

On Sun, 6 May 2001, Jeff Squyres wrote:

> A few points:
>
> 1. Implementing the change in MPI_FINALIZE to make it collective over "the
> union of all processes that have been and continue to be connected" is a
> non-trivial distributed algorithm, since it is essentially a barrier over
> potentially unrelated and not-directly-connected processes.
>
> 2. Is there a difference between "have been and continue to be connected"
> and "are connected"?
>
> 3. This change can potentially drastically change the semantics of
> currently-valid MPI programs.
>
> As one example: currently-valid "task-farm" programs may unintentionally
> cause a lot of "zombied" MPI processes that are simply waiting for an
> MPI_FINALIZE from their ancestor(s).  Consider what happens if a root
> process continually spawns short-lived MPI processes to perform some task
> in a "fire and forget" kind of model.  The short-lived child processes
> could previously invoke MPI_FINALIZE and die.  With the proposed change,
> the short-lived processed will now block waiting for the parent to invoke
> MPI_FINALIZE as well.
>
> This program can be fixed by having the root and child processes invoke
> MPI_COMM_DISCONNECT right after spawning (or after whenever the last
> message between the root and children finishes) so that the child can
> MPI_FINALIZE by itself, and then die.
>
> But my concern is backwards compatibility: we have no idea how many
> programs exist that rely on MPI_FINALIZEing over just MPI_COMM_WORLD.
> Changing the spec now could cause unintended side-effects in
> currently-valid MPI programs.
>
> {+} Jeff Squyres
> {+} jsquyres@lam-mpi.org
> {+} http://www.lam-mpi.org/
>