1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

208CHAPTER 6. GROUPS, CONTEXTS, COMMUNICATORS, AND CACHING

/* Determine my color */

MPI_Comm_rank ( multiple_server_comm, &rank ); color = rank % num_servers;

/* Split the intercommunicator */

MPI_Comm_split ( multiple_server_comm, color, rank, &single_server_comm );

The following is the corresponding server code:

/* Server	code */
MPI_Comm	multiple_client_comm;
MPI_Comm	single_server_comm;
int	rank;

/* Create intercommunicator with clients and servers: multiple_client_comm */

...

/* Split the intercommunicator for a single server per group of clients */

MPI_Comm_rank ( multiple_client_comm, &rank );

MPI_Comm_split ( multiple_client_comm, rank, 0,

&single_server_comm );

27	6.4.3 Communicator Destructors
28
29
30	MPI_COMM_FREE(comm)
31	INOUT comm	communicator to be destroyed (handle)
32

33

int MPI_Comm_free(MPI_Comm *comm)

34

35MPI_COMM_FREE(COMM, IERROR)

36INTEGER COMM, IERROR

37

fvoid MPI::Comm::Free() (binding deprecated, see Section 15.2) g

38

39This collective operation marks the communication object for deallocation. The handle

40is set to MPI_COMM_NULL. Any pending operations that use this communicator will com-

41plete normally; the object is actually deallocated only if there are no other active references

42to it. This call applies to intraand inter-communicators. The delete callback functions for

43all cached attributes (see Section 6.7) are called in arbitrary order.

44

45Advice to implementors. A reference-count mechanism may be used: the reference

46count is incremented by each call to MPI_COMM_DUP, and decremented by each call

47to MPI_COMM_FREE. The object is ultimately deallocated when the count reaches

48zero.