Re: Proposal for communicator id

Nathan E. Doss (doss@ERC.MsState.Edu)
Mon, 12 Jun 1995 18:23:11 -0500 (CDT)

>
> > I have to agree with Jim, this proposal won't work - I don't want
> > MPI_COMM_ID() to be collective (as this proposal implies).
>
> I agree it's ugly in its theory, tough not in the details of the current
> implementations. For both LAM & MPICH (and I presume other implementations
> as well, correct me if I'm wrong about other real impl.), it won't be a
> collective call, it would just return the comm. ID already stored in the
> communicator structure. The collective step is taken when the communicator
> is created. MPI_COMM_ID() would be a collective call in some theoretical
> future implementation that decides to handle communicators differently.

If we say it's collective (even thought it may not be in implementations),
applications will have to be programmed as though it is collective.

> The key issue is: what model do we want to have for a communicator? This
> is, as I understand it, Jim's main concern. In MPI-1, there is no model
> for what a communicator is "in real life" down at the byte level. On the
> other hand, a profiling or debugging tool needs to access this information.
> So it seems the solution can fall into one of several categories:

In my proposal, I specifically avoided calling anything a "context".
The "id" that I proposed does not have anything to do with contexts, but
is simply a unique identifier that one can use to distinguish between
communicators. I heartily believe we should avoid calling it a context
to avoid the implication that contexts are integers or that the id has
anything to do with MPI communication.

-- 
Nathan Doss                  doss@ERC.MsState.Edu