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
*