We do have an internal copy of the Intel MPI tests. We also down loaded a more recent copy for comparison. In both cases I do not see code in MPI_KEYVAL1_F that would differentiate between the two interpretations. All of the tests seem to follow the following general pattern: INTEGER ATTR = MPIKEYVAL_ME .... CALL MPI_COMM_SET_ATTR(comm, keyval, ATTR, ierr) .... <ATTR is not changed> .... CALL MPI_COMM_GET_ATTR(comm, keyval, ATTR, flag, ierr) <test flag or test if ATTR is MPIKEYVAL_ME> Dave -----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Thursday, April 16, 2009 9:35 AM To: Solt, David George Cc: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Alexander Supalov; Bronis de Supinski; Hans Westgaard Ry; Håkon Bugge Subject: Re: Another MPI-2.2 attribute ambiguity? On Apr 16, 2009, at 10:29 AM, Solt, David George wrote:
HP-MPI does #2.
What if the address of the variable originally passed in is no longer in scope when the corresponding comm_get_attr call is made?
Ya, that can be a problem. Do you have an internal copy of the Intel MPI tests? What does MPI_KEYVAL1_F do? Ours checks that the value of a global variable has been changed by the callbacks. I think that's why we coded it up in Open MPI this way, but I'm not sure (that was a long time ago). -- Jeff Squyres Cisco Systems