On Aug 15, 2005, at 8:59 AM, Jim Lasc wrote:
> Keep in mind that when you INTERCOMM_MERGE, you're not adding
> processes
> to an existing communicator -- you're getting an entirely new
> communicator. So using this scheme, you'll have to ditch all your
> prior requests and re-post them. This will likely be a fairly complex
> scheme, because there's race conditions that may occur (depending on
> your implementation) of messages that were sent on the old
> communicator
> but not received, etc.
>
> ->And , is there a way to "merge" two communicators, or to add one
> process to a communicator? I browsed through the MPI_Comm_x functions,
> and didn't found anything usable ?!
It depends on what you're trying to do -- if you mean "make a union of
all the processes in multiple communicators into a new communicator",
yes, there are multiple ways to do this.
But MPI guarantees two important things here:
- messages sent on one communicator will never be received on another
communicator
- communicators, once created, are fixed
So, no, you can't arbitrarily add processes to an existing communicator.
> Another option is to use pair-wise communicators, and just use an
> array
> of requests that you WAITANY (or somesuch) on. Then the communicator
> that each process is located in doesn't matter too much (except during
> startup, addition, deletion, and shutdown) during normal operations of
> sending and receiving.
> -> Do you mean, when you have a ring where each node (process) can
> speak with it's two neighbours,
> that I should make a communicator (with "members": procnr-1 ;
> procnr;procnr+1) for each node ?
> But, in that case, I still need a communicator which contains all the
> processes (to determine the procnr)? Is this correct?
Actually, I was referring to having *2* communicators -- one with (proc
X, proc X+1), and one with (proc X, proc X-1). In this sense, it would
be a distributed set of data.
As for determining identification, you'd probably have to have your own
abstraction for maintaining a unique set of processes and which
communicator(s) they belong to. This would likely be in each process
itself -- a distributed awareness of the processes that exist, and a
mapping to the communicators that they belong to in that process (quite
similar to what the MPI implementation itself does). That is, you'll
be implementing fault tolerance-like characteristics on *top* of MPI.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
