[Mpi-22] mpi-22 Digest, Vol 12, Issue 28
koziol at [hidden]
Fri Apr 3 14:01:53 CDT 2009
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]>
> 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
> 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
> delete functions for all other communicators (etc) to occur in
> 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
> 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
> that application is at least non-portable and probably should be
> buggy. If (or when) the implementation adopts the fifo order for
> 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
> 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
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2502 bytes
More information about the Mpi-22