[Mpi-22] Another MPI-2.2 attribute ambiguity?

[Jeff Squyres]

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