235. Releasing Connections
Up: Other Functionality
Next: Another Way to Establish MPI Communication
Previous: MPI_APPNUM
Before a client and server connect, they are independent
MPI applications. An error in one does not affect the other.
After establishing a connection with MPI_COMM_CONNECT
and MPI_COMM_ACCEPT, an error in one may
affect the other.
It is desirable for a client and server to be
able to disconnect, so that an error in one will
not affect the other. Similarly, it might be desirable for
a parent and child to disconnect, so that errors
in the child do not affect the parent, or vice-versa.
- Two processes are connected if there is a
communication path (direct or indirect) between them. More precisely:
1. Two processes are connected if
1. they both belong
to the same communicator (inter- or intra-,
including MPI_COMM_WORLD) or
2. they have previously belonged to a communicator
that was freed with MPI_COMM_FREE instead
of MPI_COMM_DISCONNECT or
3. they both belong to the group of the same window or
filehandle.
2. If A is connected to B and B to C, then A is connected to C.
- Two processes are disconnected (also independent)
if they are not connected.
- By the above definitions, connectivity is a transitive
property, and divides the universe of MPI processes into
disconnected (independent) sets (equivalence classes) of processes.
- Processes which are connected, but do not share the same
MPI_COMM_WORLD, may become disconnected (independent) if the
communication path between them is broken by
using MPI_COMM_DISCONNECT.
The following additional rules apply to
MPI routines in other chapters:
- MPI_FINALIZE is collective over a set of
connected processes.
- MPI_ABORT does not abort independent processes.
It may abort all processes in the caller's
MPI_COMM_WORLD (ignoring its comm
argument). Additionally, it may abort connected processes
as well, though it makes a ``best attempt'' to abort only
the processes in comm.
- If a process terminates without calling MPI_FINALIZE,
independent processes are not affected but the effect on
connected processes is not defined.
MPI_COMM_DISCONNECT(comm) |
INOUT comm | communicator (handle) |
int MPI_Comm_disconnect(MPI_Comm *comm)
MPI_Comm_disconnect(comm, ierror)
TYPE(MPI_Comm), INTENT(INOUT) :: comm
INTEGER, OPTIONAL, INTENT(OUT) :: ierror
MPI_COMM_DISCONNECT(COMM, IERROR)
INTEGER COMM, IERROR
This function waits for all pending communication on comm
to complete internally, deallocates the communicator object, and sets the handle to
MPI_COMM_NULL. It is a collective operation.
It may not be called with the communicator
MPI_COMM_WORLD or MPI_COMM_SELF.
MPI_COMM_DISCONNECT may be called only if
all communication is complete and matched, so that buffered
data can be delivered to its destination. This requirement is
the same as for MPI_FINALIZE.
MPI_COMM_DISCONNECT has the same action as
MPI_COMM_FREE, except that it waits for pending
communication to finish internally and enables the
guarantee about the behavior of disconnected processes.
Advice to users.
To disconnect two processes you may need to call
MPI_COMM_DISCONNECT, MPI_WIN_FREE,
and MPI_FILE_CLOSE to remove all communication paths
between the two processes. Note that it may be necessary to
disconnect several communicators (or to free several windows or files)
before two processes are completely independent.
( End of advice to users.)
Rationale.
It would be nice to be able to use MPI_COMM_FREE instead,
but that function explicitly does not wait for pending
communication to complete.
( End of rationale.)
Up: Other Functionality
Next: Another Way to Establish MPI Communication
Previous: MPI_APPNUM
Return to MPI-3.1 Standard Index
Return to MPI Forum Home Page
(Unofficial) MPI-3.1 of June 4, 2015
HTML Generated on June 4, 2015