[Mpi-22] Ticket #71: Add routine for registering callbackwhen finalize occurs

Jeff Squyres jsquyres at [hidden]
Thu Apr 2 15:31:46 CDT 2009



Sorry -- I didn't see this much-more-complete discussion before I  
replied to the other mail.

I agree with most of Dick's points (e.g., an MPI will likely implement  
the same mechanism for COMM_SELF as it does for all other attribute  
destruction functionality).  But I don't feel strongly one way or the  
other (apply the ordering just to COMM_SELF or to all attribute  
destruction).  To me, the COMM_SELF attribute destruction stuff is  
already a hack -- elegant or not -- so adding ordering on it is no big  
deal.  But like I said, I don't have strong feelings either way.

On Mar 30, 2009, at 10:09 AM, Richard Treumann wrote:

> 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.
>
>
>
> Dick Treumann - MPI Team
> IBM Systems & Technology Group
> Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
> Tele (845) 433-7846 Fax (845) 433-8363
>
>
> mpi-22-bounces_at_[hidden] wrote on 03/28/2009 11:57:19 PM:
>
> > [image removed]
> >
> > Re: [Mpi-22] Ticket #71: Add routine for registering callback when
> > finalize occurs
> >
> > Quincey Koziol
> >
> > to:
> >
> > mpi-22
> >
> > 03/30/2009 09:28 AM
> >
> > Sent by:
> >
> > mpi-22-bounces_at_[hidden]
> >
> > Please respond to "MPI 2.2"
> >
> >
> > > Date: Thu, 26 Mar 2009 13:24:26 -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:
> > >    <OFE2F8673A.D3771BE2-
> > > ON85257585.005F95BC-85257585.005F9F47_at_[hidden]>
> > > Content-Type: text/plain; charset="us-ascii"
> > >
> > > Why would this be specific to MPI_COMM_SELF?  If this is the right
> > > thing to
> > > do, shouldn't it apply to attribute delete functions on all  
> disposed
> > > objects?
> >
> >    The ticket is oriented to what happens at MPI_Finalize, really,  
> and
> > not so much about MPI_COMM_SELF per se.  The attribute callback on
> > MPI_COMM_SELF was just the accepted way in the standard to "have
> > something happen" when MPI_Finalize was called.
> >
> >    Quincey
> >
> > > Dick Treumann  -  MPI Team
> > > IBM Systems & Technology Group
> > > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
> > > Tele (845) 433-7846         Fax (845) 433-8363
> > >
> > >
> > > mpi-22-bounces_at_[hidden] wrote on 03/26/2009 12:50:40  
> PM:
> > >
> > >> [image removed]
> > >>
> > >> [Mpi-22] Ticket #71: Add routine for registering callback when
> > >> finalize
> > > occurs
> > >>
> > >> Quincey Koziol
> > >>
> > >> to:
> > >>
> > >> mpi-22
> > >>
> > >> 03/26/2009 12:54 PM:
> > >>
> > >> Sent by:
> > >>
> > >> mpi-22-bounces_at_[hidden]
> > >>
> > >> Please respond to "MPI 2.2"
> > >>
> > >> Hi all,
> > >>  Could another two people review this ticket for specifying the  
> order
> > >> that attribute delete callbacks should be made:
> > >>
> > >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71
> > >>
> > >>  Thanks,
> > >>     Quincey
> > >>
> > >> [attachment "smime.p7s" deleted by Richard Treumann/Poughkeepsie/
> > >> IBM] _______________________________________________
> > >> mpi-22 mailing list
> > >> mpi-22_at_[hidden]
> > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
> > > -------------- next part --------------
> > > HTML attachment scrubbed and removed
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > mpi-22 mailing list
> > > mpi-22_at_[hidden]
> > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
> > >
> > >
> > > End of mpi-22 Digest, Vol 12, Issue 26
> > > **************************************
> > >
> >
> > [attachment "smime.p7s" deleted by Richard Treumann/Poughkeepsie/
> > IBM] _______________________________________________
> > mpi-22 mailing list
> > mpi-22_at_[hidden]
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22


-- 
Jeff Squyres
Cisco Systems




More information about the Mpi-22 mailing list