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

[Solt, David George]

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?

Dave

-----Original Message-----
From: Jeff Squyres [mailto:jsquyres_at_[hidden]] 
Sent: Thursday, April 16, 2009 9:19 AM
To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Alexander Supalov; Bronis de Supinski; Solt, David George; Hans Westgaard Ry; Håkon Bugge
Subject: Another MPI-2.2 attribute ambiguity?

This is related to -- but different from -- MPI 2.2 ticket #55
("MPI-2.1 Cross-language attribute example is wrong").  Explicitly adding all the #55 CC members to this mail, plus a few others.

I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific behavior regarding the EXTRA_STATE arguments passed to the Fortran keyval copy and delete functions (both the ADDRESS_KIND and deprecated flavors).  I see two choices:

1. pass the user's original EXTRA_STATE argument by reference to the callbacks, or 2. copy the user's original EXTRA_STATE into internal MPI storage and pass *that* value by reference to the callbacks

==> Open MPI currently does #1.  What do other implementations do?

I raise this issue because the text does not indicate which way is right.  And I just ran across an old Sun test that assumed #2.  But our internal copy of the Intel MPI tests assume #1 (to be fair: I have no idea if the Intel tests originally assumed #2 and we changed them to #1 over time).  Indeed, #2 is actually in-line with the philosophy of storing attribute values in internal MPI storage.  E.g.:

   INTEGER foo = 4
   INTEGER bar
   CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr)
   foo = 5
   CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr)

bar should equal 4, not 5 (right?).

So what does that mean (or imply) about the EXTRA_STATE value passed to the Fortran callbacks?


--
Jeff Squyres
Cisco Systems