This section introduces four blocking inter-communicator operations.
MPI_INTERCOMM_CREATE is used to bindtwo intra-communicators into an inter-communicator; the function
MPI_INTERCOMM_MERGE creates an intra-communicator by
merging the local and remote groups of an inter-communicator. The
functions
MPI_COMM_DUP and
MPI_COMM_FREE, introduced previously,
duplicate and free an inter-communicator, respectively.
Overlap of local and remote groups that are bound into an inter-communicator is prohibited. If there is overlap, then the program is erroneous and is likely to deadlock. (If a process is multithreaded, and MPI calls block only a thread, rather than a process, then ``dual membership'' can be supported. It is then the user's responsibility to make sure that calls on behalf of the two ``roles'' of a process are executed by two independent threads.)
The function MPI_INTERCOMM_CREATE can be used to create an inter-communicator from two existing intra-communicators, in the following situation: At least one selected member from each group (the ``group leader'') has the ability to communicate with the selected member from the other group; that is, a ``peer'' communicator exists to which both leaders belong, and each leader knows the rank of the other leader in this peer communicator. Furthermore, members of each group know the rank of their leader.
Construction of an inter-communicator from two intra-communicators requires separate collective operations in the local group and in the remote group, as well as a point-to-point communication between a process in the local group and a process in the remote group.
In standard MPI implementations (with static process allocation at initialization), the MPI_COMM_WORLD communicator (or preferably a dedicated duplicate thereof) can be this peer communicator. For applications that have used spawn or join, it may be necessary to first create an intracommunicator to be used as peer. The application topology functions described in Chapter Process Topologies do not apply to inter-communicators. Users that require this capability should utilize MPI_INTERCOMM_MERGE to build an intra-communicator, then apply the graph or cartesian topology capabilities to that intra-communicator, creating an appropriate topology-oriented intra-communicator. Alternatively, it may be reasonable to devise one's own application topology mechanisms for this case, without loss of generality.
MPI_INTERCOMM_CREATE(local_comm, local_leader, peer_comm, remote_leader, tag,
newintercomm)
int MPI_Intercomm_create(MPI_Comm local_comm, int local_leader, MPI_Comm peer_comm, int remote_leader, int tag, MPI_Comm *newintercomm)
MPI_INTERCOMM_CREATE(LOCAL_COMM, LOCAL_LEADER, PEER_COMM, REMOTE_LEADER, TAG, NEWINTERCOMM, IERROR)
INTEGER LOCAL_COMM, LOCAL_LEADER, PEER_COMM, REMOTE_LEADER, TAG, NEWINTERCOMM, IERROR
MPI::Intercomm MPI::Intracomm::Create_intercomm(int local_leader, const MPI::Comm& peer_comm, int remote_leader, int tag) const
This call creates an inter-communicator. It is collective
over the union of the local and remote groups. Processes should
provide identical local_comm and local_leader
arguments within each group.
Wildcards are not permitted for
remote_leader, local_leader, and tag.
This call uses point-to-point communication with communicator peer_comm, and with tag tag between the leaders. Thus, care must be taken that there be no pending communication on peer_comm that could interfere with this communication.
Advice to users.
We recommend using a dedicated peer communicator, such as a duplicate
of MPI_COMM_WORLD, to avoid trouble with peer communicators.
( End of advice to users.)
MPI_INTERCOMM_MERGE(intercomm, high, newintracomm) | |
IN intercomm | Inter-Communicator (handle) |
IN high | (logical) |
OUT newintracomm | new intra-communicator (handle) |
int MPI_Intercomm_merge(MPI_Comm intercomm, int high, MPI_Comm *newintracomm)
MPI_INTERCOMM_MERGE(INTERCOMM, HIGH, INTRACOMM, IERROR)
INTEGER INTERCOMM, INTRACOMM, IERROR
LOGICAL HIGH
MPI::Intracomm MPI::Intercomm::Merge(bool high) const
This
function creates an intra-communicator from the union of
the two groups that are associated with intercomm.
All processes should provide the same
high value within each of the two groups. If processes in one group
provided the value high = false and processes in the other group
provided the value high = true then the union orders the ``low'' group
before the ``high'' group. If all processes provided the same high
argument then the order of the union is arbitrary.
This call is blocking and collective within the union of
the two groups.
The error handler on the new intercommunicator in each process is inherited from the communicator that contributes the local group. Note that this can result in different processes in the same communicator having different error handlers.
Advice
to implementors.
The implementation of
MPI_INTERCOMM_MERGE,
MPI_COMM_FREE and MPI_COMM_DUP are
similar to the implementation of
MPI_INTERCOMM_CREATE, except
that contexts private to the input inter-communicator
are used for
communication between group leaders rather than contexts inside a
bridge communicator. ( End of advice to implementors.)