On Sat, 21 Jun 2003, Sherif Abd El-Momen wrote:
> How can I volintarly kill one of the process. And latter on can perform
> collective communication, for example MPI_Spawn.
Not sure what you mean here. If you want a spawned process to die, it can
just call MPI_FINALIZE. However, that does potentially present a problem
for collectives later -- since, by definition, all collectives must
involve all members of the communicator.
We've had many discussions about this among ourselves, and the best way
that we can think to do this is to always spawn processes individually
(i.e., a pairwise intercommunicator with the parent). Then do a series of
merges/creates (*1*) to make a megga-intracommunicator on which you can do
collectives. Then, when you want a spawned process to die, have everyone
in the mega-intracommunicator do a MPI_COMM_SPLIT, and the
process-about-to-die and supply MPI_UNDEFINED; this will make a new
mega-intracommunicator without the about-to-die process. Then everyone
frees the original mega-intra, and the about-to-die process can call
MPI_FINALIZE.
There's obviously more details than that, but that's the gist of it.
The killer part is (*1*). Say you have a root R, and it has already
spawned processes A and B. You want to spawn C, and make a mega-intra
that covers all of (R, A, B, C). How do you do this? There's a variety
of ways, none of which are nice. Here's some examples:
1. When R wants to spawn C, A and B are notified so that the SPAWN is
collective over R, A, and B. Then everyone just knows about everyone else
from the beginng, and making the mega-intra is easy (INTERCOMM_MERGE).
But if someone wants to leave (for example, B), it becomes problematic
because then C's parent communicator will have a hole in it.
Technically, LAM won't care if you don't try to use C's parent
communicator to communicate with B (including collectives), and
technically it's legal MPI (B called MPI_FINALIZE, after all), but you may
run into problems -- MPI_FINALIZE is intentionally defined rather fuzzily
in the standard.
2. R itself spawns C, and then notifies A and B. C then does
ACCEPT/CONNECT kinds of calls to establish intercommunicators with A and
B, and when that's all done, R, A, B, and C do an MPI_COMM_CREATE with a
group (since all processes know about each other, albiet via different,
non-intersecting communicators). This doesn't suffer from the problem of
(1), where if B dies you may get Badness. But it may be more annoying
because A and B have to watch for connections from new processes (which is
actually somewhat similar to A and B having to participate in SPAWNs, as
well).
....
I'm sure you can come up with other schemes as well. But it's probably
nasty any way that you do it.
Be sure to let us know what your final solution is; I'd be interested to
see this kind of model work.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
