5.5.4. 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 don't 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-1 functions:
  • MPI_FINALIZE is collective over a set of connected processes.
  • MPI_ABORT does not abort independent processes. As in MPI-1, it may abort all processes in 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)
INTEGER COMM, IERROR

void MPI::Comm::Disconnect()

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. Notes 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-2 Standard Index
MPI-2.0 of July 18, 1997
HTML Generated on August 11, 1997