[Mpi-22] mpi-22 Digest, Vol 13, Issue 4
koziol at [hidden]
Sat Apr 4 22:42:35 CDT 2009
On Apr 4, 2009, at 10:57 AM, mpi-22-request_at_[hidden] wrote:
> Message: 2
> Date: Fri, 3 Apr 2009 13:13:04 -0700 (PDT)
> From: "Bronis R. de Supinski" <bronis_at_[hidden]>
> Subject: Re: [Mpi-22] mpi-22 Digest, Vol 12, Issue 28
> To: "MPI 2.2" <mpi-22_at_[hidden]>
> Message-ID: <Pine.LNX.4.58.0904031311180.3888_at_[hidden]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 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.
Thanks for the encouragement. :-) OK, I'll go through the standard
and figure out the places that should be changed. However, I'm going
to create a new ticket for this change, since I don't want to hold up
ticket #71 and this new idea is tangential to the primary purpose of
> 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
>>> 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
>>> 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).
>>> 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
>>> 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
>>> 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