Re: Communicator IDs & Dynamic Processes

Steve Huss-Lederman (lederman@cs.wisc.edu)
Thu, 9 May 1996 16:51:29 -0500

>
> Will the values of MPI_COMM_ID_UNIQUE, MPI_COMM_ID_GLOBAL
> and MPI_COMM_ID_NOT_GLOBAL (as mentioned in section 6.3.4
> page 15 lines 9-28) become redundant due to the new
> dynamic abilities of MPI-2? For example when two sets
> of independant processes join together there will be
> two MPI_COMM_WORLDs, also the superset of all processes
> will not be readily identifiable. Having global or
> unique identifiers in one process is alright but trying
> to ensure that they are global or unique across all
> jobs that might merge is another. With these new
> dynamic abilities it will be harder for a profiler or
> debugger to uniquely identify a process as rank in
> MPI_COMM_WORLD does not have the same meaning as in
> MPI-1 and no superset or universe of worlds is
> readily identifiable without tracing many calls.

Mark raises a good point. I debated whether it was sufficient to have
the attribute on MPI_COMM_WORLD or each communicator. The problem
with each communicator is that if it changes in the middle then a tool
would be in trouble unless it was pessimestic from the start.
However, I'm not yet convinced that having it on MPI_COMM_WORLD will
not work. My logic was that whenever you modify the group of
processes involved you create a new communicator. Thus, the MPI
implementation could then control whether it gives a unique ID to the
comm whether or not it is created by dynamic processes. However, it
may be that no implementation will be globally unique once we have
dynamic processes. Is that true?

Now the other point seems to be that you cannot translate from your
(rank, comm) into a (rank, MPI_COMM_WORLD) if you have dynamic
processes. This is true. Profilers may need to capture information
about dynamic process creation to make sense of the rank in the comm.
However, if the tool wants to tell an absolute node id it needs to do
this with or without dynamic processes. I was under the impression
that what profilers would do is get the rank of the process involved
(partner) and also given the ID they could uniquely match them up with
other uses (for example, to match the send and recv pair). There was
no need to necessarily get a unique global ID. Is this what people
had in mind?

Steve