> Suggested solution
> [1 or 2].C
[summary: either a new function or a predefined communicator attribute,
and the comm ID is unique in a proc, the same for all procs in a comm,
but may be used by mutually exclusive proc groups]
I suggest solution 1.E, introducing the MPI_COMM_ID() function instead
of the predefined communicator attribute. This allows for point E below,
in which I hope to answer Jim's (and Lloyd's?) concerns/unease.
D. The value cannot be reused by a member process after a communicator
is system-wide terminated (i.e. freed by all and with no pending
communication).
[Rationale: This would allow debugging tools to cache information about
the communicator if necessary. Acquiring such information from the
system would probably be very intrusive. The ability to cache it per
process would significantly reduce this intrusiveness. This point is
also consistent with Leslie & Tom's datatype proposal.]
E. An implementation is not required to have or use a communicator ID
to represent the MPI context during normal operations. This position
is consistent with MPI-1. However, the first time MPI_COMM_ID() is
called for a given communicator, the system is required to take the
necessary steps to generate a communicator ID that satisfies the
constraints imposed by point C.
[Rationale: This allows MPI implementations to use more suitable context
representations (if possible) during normal operations. Only when, for
debugging purposes, a user calls MPI_COMM_ID() is the system required to
generate a communicator-wide and process-wide unique ID by making a global
synchronization. Having such a standard external representation for the
context promotes the portability of MPI debugging tools, without hindering
the performance of production code.]
--Raja