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

[Richard Treumann]

H Quincy

Only Jeff has made any statement about his preference and he did not make a
strong one.  We will need to see what the Forum thinks next week.

I added a comment to the ticket today.  I think that having a LIFO order
for attribute detach function callbacks is reasonable and not a very big
burden on implementors.  Bill Gropp mentioned that MPICH uses a hash table
and would need to revise their code but he did not think it would be very
difficult.

It seems reasonable to me to say that all objects that cache attributes
must record them in order so that attribute delete and attribute copy
callback functions can be executed in a predictable order.  For delete
callbacks the logical order is LIFO.  Since we previously said the order
was arbitrary for both delete and copy, it cannot break any compliant MPI
application if copy functions also are triggered in LIFO order.

If somebody argues attribute copy functions should be triggered in FIFO
order, things get a bit messy but still not too bad.

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 04/03/2009 03:01:53 PM:

> [image removed]
>
> Re: [Mpi-22] mpi-22 Digest, Vol 12, Issue 28
>
> Quincey Koziol
>
> to:
>
> mpi-22
>
> 04/03/2009 03:04 PM
>
> Sent by:
>
> mpi-22-bounces_at_[hidden],
>
> Please respond to "MPI 2.2"
>
> 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
>
> [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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20090403/16351cfd/attachment.html>