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

[Solt, David George]

Yes, I was focused on ATTR and not the extra_state aspect.  It looks like we did modify the Intel test suite in this case.   We basically included our own method to count the number of times the callback was called and did not use the EXTRA_STATE "feature" as a method to do this.  So, you are correct that the Intel test suite (unmodified) will fail with approach #2.  Apparently, our founding fathers here on HP-MPI believed very strongly that the Intel test was bogus and we were doing the right thing. 

Dave 

-----Original Message-----
From: Jeff Squyres [mailto:jsquyres_at_[hidden]] 
Sent: Thursday, April 16, 2009 4:14 PM
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?

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