OK.
Thanks a lot.
On 8/16/05, Jeff Squyres <jsquyres_at_[hidden]> wrote:
>
> 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/
>
>
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
|
