[Mpi3-tools] Tools WG webex: tomorrow!

[George Bosilca]

On Jul 1, 2013, at 20:37 , David Goodell (dgoodell) <dgoodell at cisco.com> wrote:

> On Jul 1, 2013, at 12:33 PM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
> 
>> On Jul 1, 2013, at 1:24 PM, "David Goodell (dgoodell)" <dgoodell at cisco.com> wrote:
>> 
>>> ----8<----
>>>> 	• Jeff also brings up the idea of a callback (or some kind of MPI_T notification) to know when an MPI object is destroyed (per email conversation w/ Jeff, Kathryn, Martin).
>>>> 		• Marc-Andre will think about whether it will be useful for any tools to know when MPI objects get destroyed.
>>>> 		• Marc-Andre will also think about whether it would be useful for there to be an MPI_T mechanism to get some kind of unique ID for an MPI object (that will be durable after the handle is freed). This way, a tool can track the entire lifecycle of an object -- not just its handle.
>>> ----8<----
>>> 
>>> I was unable to attend the call, but why isn't attaching an attribute with a destructor callback to the object in question sufficient?  Is it because we have MPI opaque objects which do not support attributes (e.g., MPI_Op)?
>> 
>> 
>> Today's attribute calls give you a callback when MPI_*_FREE is invoked -- when is potentially not when the object is actually destroyed.
>> 
>> The Fab+Jeff idea was wondering if anyone cares about the difference between these two; are there any useful use cases where someone could benefit from knowing when the object was actually destroyed?
> 
> I don't think the standard is clear enough on this point.  The most relevant text that I found (MPI-3.0, pp.269-270) is reproduced below:
> 
> ----8<----
>    Analogous to comm_copy_attr_fn is a callback deletion function, defined as follows. The comm_delete_attr_fn function is invoked when a communicator is deleted by MPI_COMM_FREE or when a call is made explicitly to MPI_COMM_DELETE_ATTR. comm_delete_attr_fn should be of type MPI_Comm_delete_attr_function.
>    This function is called by MPI_COMM_FREE, MPI_COMM_DELETE_ATTR, and MPI_COMM_SET_ATTR to do whatever is needed to remove an attribute. The function returns MPI_SUCCESS on success and an error code on failure (in which case MPI_COMM_FREE will fail).
>    The argument comm_delete_attr_fn may be specified as MPI_COMM_NULL_DELETE_FN from either C or Fortran. MPI_COMM_NULL_DELETE_FN is a function that does nothing, other than returning MPI_SUCCESS. MPI_COMM_NULL_DELETE_FN replaces MPI_NULL_DELETE_FN, whose use is deprecated.
>    If an attribute copy function or attribute delete function returns other than MPI_SUCCESS, then the call that caused it to be invoked (for example, MPI_COMM_FREE), is erroneous.
> ----8<----
> 
> I'm fairly sure that MPICH interprets the standard to mean invoke comm_delete_attr_fn at actual object destruction time, which may be some time after MPI_COMM_FREE returns.
> 
> I believe that the "at destruction time" interpretation is the most useful one, even if it's not clearly mandated nor universally implemented.

I have to disagree as I do believe that once there is no way to access an object, and as a side-effect the attributes attached to it, there is absolutely no reason to delay their release. 

Maybe a even stronger case why the destruction of the attributes should be done when MPI_*_Free is called is the behavior imposed on MPI_COMM_SELF. The standard states at page 363 line 14 "When MPI_FINALIZE is called, it will first execute the equivalent of an MPI_COMM_FREE on MPI_COMM_SELF. Thus will cause the delete callback function to be executed on all keys associated with MPI_COMM_SELF, in the reverse other that they were set on MPI_COMM_SELF. … The 'freeing' of MPI_COMM_SELF occurs before any other parts of MPI are affected".

Of course one can have a special code-path for the case mentioned above, but a consistent behavior over all calls (equivalent or not) to a particular MPI function is more suitable.

That being said I do confirm that Open MPI interprets the standard the "other" way, the attribute delete function is called upon MPI_*_Free and not delayed until the object itself is freed internally by the library.

George.



> 
> -Dave
> 
> 
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools