[Mpi-forum] MPI attribute callback behavior

Dave Goodell goodell at mcs.anl.gov
Mon Apr 25 12:36:10 CDT 2011


Jeff,

I think I agree with all of your conclusions from this original email, but I don't necessarily agree with your justification for some of them.  Mainly, the deletion callbacks can be invoked even when the object itself isn't being freed (via MPI_<FOO>_delete_attr, for example).  So justifications like "why allow setting an object that is being deleted?" strike me as invalid.  

I think a better case for disallowing these sorts of actions is that (1) there seems to be no compelling use case for them, and (2) it could be tricky to correctly handle these cases because they could easily result in recursion in the attribute/callback mechanisms.

-Dave

On Apr 14, 2011, at 9:36 AM CDT, Jeff Squyres wrote:

> An issue recently came up within Open MPI as to what exactly you are allowed to do within an attribute callback (e.g., when a communicator is copied or deleted).  
> 
>> From a standards point of view (i.e., regardless of implementation), here's a list that we came up with:
> 
> 1. While in a keyval copy callback with original object A and new object B:
>  - Call MPI_Comm_get_attr on A: ok
>  - Call MPI_Comm_get_attr on B: erroneous 
>    (B is still being created, and therefore the get is non-deterministic)
>  - Call MPI_Comm_set_attr on A: erroneous
>    (seems like a bad idea to modify what you're in the middle of copying)
>  - Call MPI_Comm_set_attr on B: erroneous (non-deterministive) if keyval exists on A, otherwise ok
>  - Call MPI_Comm_delete_attr on A: erroneous
>    (seems like a bad idea to modify what you're in the middle of copying)
>  - Call MPI_Comm_delete_attr on B: erroneous (non-deterministic)
>    (same as get_attr on B, above)
>  - Call MPI_Comm_create_keyval: ok
>  - Call MPI_Comm_free_keyval: ok
> 
> 2. While in a keyval delete callback on object A:
>  - Call MPI_Comm_get_attr on A: erroneous
>    (A is being deleted; that attribute may have already been deleted)
>  - Call MPI_Comm_set_attr on A: erroneous
>    (why allow setting on an object that is being deleted?)
>  - Call MPI_Comm_delete_attr on A: erroneous
>    (it's going to be deleted anyway)
>  - Call MPI_Comm_create_keyval: ok
>  - Call MPI_Comm_delete_keyval: ok
> 
> Does anyone disagree with this list?
> 
> Should we put some kind of list like this in MPI-3?  (I can work up a ticket if we think supporting text like this should be there)
> 
> -- 
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum





More information about the mpi-forum mailing list