What about when you call COMM_DUP? That's when the COPY callback will be invoked. In my copy of MPI_Keyval1_f.F, in COPY_FUNCTION1, it does the following: EXTRA_STATE = EXTRA_STATE + 1 And then later in the application, it checks the value of EXTRA1 to see if it was incremented to 3 (by calling COPY_FUNCTION1 3 times). Hence, it's assuming that EXTRA_STATE in COPY_FUNCTION1 is really a reference to a global variable -- not a pointer to internal MPI state. Does yours not do that? On Apr 16, 2009, at 5:09 PM, Solt, David George wrote:
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
-- Jeff Squyres Cisco Systems