> In PVM, we have this notion of "being spawned". At startup time, then, a PVM
> process gets to find out whether it has, in fact, been spawned. If so, it may
> conclude that it is the "master" and may start spawning off slave copies of
> itself. I think that this is a very important point to note: the same
> executable image works for both master and slave.
Even in the context of PVM, this doesn't work too well. I've seen
more than one case where a user had an SPMD application in which
process 0 spawns processes 1...N-1. It decides whether it is the
parent by checking whether it has a parent. This is fine if you
start the original from the command line, but if you start the
original from the PVM console (a reasonable thing to do),
it has a parent (the console) - the program fails and the
user is puzzled. The analogy in MPI is the case where mpirun
is implemented using Spawn(). Fortunately through the
INDEPENDENT calls mpirun is able to disown the children so that
they don't see a parent.
> The second choice is to use two different executable images, one for the master
> and one for the slaves. I claim that fundamentally, this is exactly the model
> that MPI programmers will eventually have to start using because it is the only
> way that I know of to address these conflicting goals. An MPI-2 program should
> not ever need to call MPI_Have_I_been_spawned() because it will already know
> this implicitly.
> So all that we lose is the ability to compile everything into one nice clean
> image. While this would certainly be nice, I don't see any way to make it work
> given the lack of restrictions that we are currently mandating in our execution
Hopefully you are not advocating that for an SPMD program, there
should be two separate programs!
In the case of a truly SPMD model, I advocate keying off rank
in MPI_COMM_WORLD instead of trying to do fancy things with spawn()
and MPI_Have_I_been_spawned(). I agree with Al, though, that
it should be *possible* to start an SPMD MPI program by spawning
(since it is occasionally necessary, even though it it may often
be misguided) so we should make sure we have enough mechanism
to do it.
For a truly MPMD model, there's no problem, as you point out.