[mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn

[Fab Tillier]

Pavan Balaji wrote on Mon, 20 May 2013 at 09:03:04

> 
> On 05/20/2013 10:49 AM US Central Time, Fab Tillier wrote:
>> Pavan Balaji wrote on Mon, 20 May 2013 at 06:57:42
>> 
>>>> And what about the non-deterministic effects that I called out in
>>>> the email back in 2011 -- are those allowed, and if so, do we
>>>> need to say that they're non-deterministic?  ...and so on.-
>>> 
>>> Right, we did talk about the non-determinism on this email thread
>>> before you joined in, but we concluded that there's only one
>>> sensible way.  Of course, that should be clarified in the standard.
>>> But it's not a major change in implementations, I think.
>> 
>> One thing we didn't discuss yet is whether the callbacks are called
>> during MPI_Finalize, for attributes assigned to built-in
>> communicators and/or types, and what operations are allowed therein.
>> This makes it that much more interesting to do non-blocking I/O from
>> the callback, since technically the application has called
>> MPI_Finalize. However, if we go with the "as if MPI_*_DELETE_ATTR was
>> called before the call, then anything should be valid, and we should
>> have an advice to users regarding Finalize.
> 
> Are we supposed to call those callbacks at Finalize?  MPI is not
> required to clean up the comm resources, is it?

In MPI-3, section 8.7.1 (page 363) states that delete callbacks are invoked on MPI_COMM_SELF before anything else happens, and that MPI_FINALIZED will return false from any of these delete callbacks.  There's no mention about attribute callbacks on other built-in communicators, and no mention of behavior for built-in types.  Likely they should be invoked too for consistency's sake.

What's interesting is that this section states that there is an ordering enforced (reverse from the order in which they are set), while MPI_COMM_FREE (page 248) states that the callbacks are invoked in arbitrary order.

We should probably make that consistent, and to preserve backward compatibility, the "arbitrary order" may have to become stricter for implementations to match the finalize behavior.

Cheers,
-Fab