[Mpi-forum] MPI attribute callback behavior

[Jeff Squyres]

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/