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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/