Re: MPI_FINALIZE

["Andrew Lumsdaine" <lums@lsc.nd.edu>]

Hum. If I understand the idea of "collective" properly, then I don't see how
this can be accomplished without something like a barrier occurring.  Does
not the requirement that all the processes have to call the MPI routine also
imply that it is an error if they do not all do so?  Does not that also
imply that each process needs to wait until all processes have made the
collective call in order to know whether the collective call has been
properly made or not?

Otherwise, I don't think MPI_Finalize would be truly collective.  I.e., if
one can call it and receive indication of success regardless of whether
anyone else ever calls it or not, then it seems like a local procedure.


----- Original Message -----
From: "Rolf Rabenseifner" <rusrabe@awsrr.rus.uni-stuttgart.de>
To: "Jeff Squyres" <jsquyres@lam-mpi.org>
Cc: <mpi-21@mpi-forum.org>
Sent: Thursday, May 10, 2001 3:49 AM
Subject: Re: MPI_FINALIZE


> (This mail is a response to the Mail of Jeff and the replies from Hubert
and Tony)
>
> As far as I know, an MPI routine is "collective" over a group of
> processes means that all these processes have to call the
> MPI routine in a way, that the collective MPI routine is allowed to
> make a barrier synchronization internally,
> but it does __NOT__ mean that the MPI routine must do such a barrier.
>
> I.e. it is always allowed to implement MPI_Finalize in a way,
> that it delivers all pending messages to the destination processes
> and then it exits the process in a way, that the other MPI processes
> are not touched (or killed or...).
>
> Therefore, the sentence "MPI_FINALIZE is collective over "the
> union of all processes that have been and continue to be connected"
> has no impact on the implementation.
> It has also no impact on the application, because it is trivial, that
> all processes have to call MPI_Finalize exactly once.
>
> And I do not see any dfference between "are connected" and
> "have been and continue to be connected".
>
> And each implementor should check, whether it makes sense
> to do a barrier inside of MPI_Finalize or whether such a barrier is
> mainly a performance drawback.
>
> Is my answer correct, or does I have overlooked some lines in
> the standard that imply a barrier inside of MPI_Finalize?
>
> Rolf
>
>
> > 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/
> >
>
>
>
> Dr. Rolf Rabenseifner                      High Performance Computing
> Parallel Computing                         Center Stuttgart    (HLRS)
> Rechenzentrum Universitaet Stuttgart (RUS) Phone:    ++49 711 6855530
> Allmandring 30                             FAX:      ++49 711 6787626
> D-70550 Stuttgart                   rabenseifner@rus.uni-stuttgart.de
> Germany                        http://www.hlrs.de/people/rabenseifner
>