[Mpi-22] mpi-22 Digest, Vol 13, Issue 4

[Quincey Koziol]

Hi Bronis,

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
>
>
> 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.

        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  
ticket #71.

        Quincey

> 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




* 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2502 bytes
Desc: smime.p7s
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20090404/d5f573e9/attachment.bin>