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

Quincey Koziol koziol at [hidden]
Fri Apr 3 14:01:53 CDT 2009


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/20090403/e7254172/attachment.bin>


More information about the Mpi-22 mailing list