[Mpi3-tools] Tools WG webex: tomorrow!

[Fab Tillier]

Jeff Squyres (jsquyres) wrote on Mon, 1 Jul 2013 at 15:19:33

> 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)

Yes, and Dave highlighted the relevant section, specifically the paragraph starting on page 269 line 40:
"This function is called by MPI_COMM_FREE ... to do whatever is needed to remove an attribute.  The function returns ... an error code on failure (in which case MPI_COMM_FREE will fail)."

The second sentence defines behavior, and IMO eliminates any question as to the meaning "is called by".

-Fab

> 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