[Mpi3-tools] Tools WG webex: tomorrow!

[Jeff Squyres (jsquyres)]

Fab --

I thought that you and Anh had found a specific place where you claimed that the current system was mandated to invoke the attribute delete callbacks at FREE time, not object destruction time.

Can you cite what that was?  (I'm not sure if you're on the mpi3-tools list; if you're not, I can forward your reply)



On Jul 1, 2013, at 2:37 PM, 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.
> 
> -Dave
> 
> 
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/