[Mpi-22] mpi-22 Digest, Vol 12, Issue 28

[Bronis R. de Supinski]

Quincy:

A consistent order for MPI_COMM_SELF  seems necessary for
the functionality that you need. Dick's comments that making
it consistent for all communicators makes a lot of sense. If
you put in the effort to find the places it needs to be
fixed then LLNL would support your proposed change.

Bronis

On Fri, 3 Apr 2009, Quincey Koziol wrote:

> Hi Dick,
>
> On Mar 30, 2009, at 11:00 AM, treumann_at_[hidden] wrote:
>
> > Message: 3
> > Date: Mon, 30 Mar 2009 10:09:44 -0400
> > From: Richard Treumann <treumann_at_[hidden]>
> > Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback
> > 	when		finalize occurs
> > To: "MPI 2.2" <mpi-22_at_[hidden]>
> > Message-ID:
> > 	<OF78D7D349.90931954-
> > ON85257589.004B887F-85257589.004DCBDF_at_[hidden]>
> > Content-Type: text/plain; charset="us-ascii"
> >
> >
> > I understand that the immediate motive is associated with the use of
> > attribute delete callbacks that occur when MPI_COMM_SELF is freed at
> > MPI_FINALIZE.
> >
> > That does not alter the fact that when MPI-2 imposed an implicit
> > free of
> > MPI_COMM_SELF in MPI_FINALIZE to allow the use of attribute delete
> > functions for cleanup it  involved a narrow extension of a general MPI
> > facility related to attributes and certain object types. To allow
> > attribute
> > delete functions for all other communicators (etc) to occur in
> > arbitrary
> > order while demanding that attribute delete for MPI_COMM_SELF have a
> > standards defined order is an inelegant hack (in my opinion).  Freeing
> > MPI_COMM_SELF within MPI_FINALIZE was a relatively elegant hack
> > because it
> > did not introduce inconsistency.
> >
> > Add to that the probability that an MPI implementor is likely to use
> > the
> > same algorithms for all attribute management rather than write
> > special case
> > code for MPI_COMM_SELF leads me to argue that if a defined order for
> > attribute delete callbacks is adopted it should be adopted broadly to
> > maintain a consistent flavor across the standard.
> >
> > If an existing MPI implementation is currently deleting in some
> > other order
> > and an application happens to work on that MPI only because of that
> > order,
> > that application is at least non-portable and probably should be
> > considered
> > buggy.  If (or when) the implementation adopts the fifo order for
> > attribute
> > deletes on "user_comm" it would be clear that the implementation
> > change had
> > not "broken the user".
> >
> > A general mandate that attribute deletion callbacks on all object
> > types
> > must occur in fifo order for an implementation to be MPI 2.2 compliant
> > should not break any "correct" MPI application and should not be
> > noticeably
> > harder for implementors.
> >
> > It will require tracking down all places in the standard that
> > currently say
> > the order is arbitrary so it is harder to get all ducks in a row for
> > the
> > ticket.
>
> 	I'm willing to do the work to find the places in the standard which
> need to change, but need some general feedback about whether this is
> desired.  Any opinions?  Personally, I think it would be easier for
> implementors and more understandable to users to make things
> consistent across all attributes also, rather than treating
> MPI_COMM_SELF in a special way for the order of the delete callbacks.
>
> 	Quincey
>
>