Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
Yes, this is worth an ATI - the fact that we traded this much mail on it is proof of that :) Thanks, Jeff. Bill On Apr 17, 2009, at 8:14 AM, Jeff Squyres wrote:
Someone pointed out to me this morning that there's no restriction on the value of EXTRA_STATE when CREATE_KEYVAL is invoked -- it may be an expression, for example. I think that pretty much seals the deal that #2 is the correct way.
I think that this is worth an ATI in the text; does anyone disagree? I volunteer to write it up/make a 3.0 ticket (hey, first ticket for the Misc WG! :-) ) if no one disagrees.
On Apr 17, 2009, at 8:59 AM, Supalov, Alexander wrote:
Hi,
Intel MPI (and most likely other MPICH2 derivatives) appears to use method #2.
Best regards.
Alexander
-----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Thursday, April 16, 2009 4:19 PM To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Supalov, Alexander; Bronis de Supinski; David Solt; 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
--------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
-- Jeff Squyres Cisco Systems
William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
participants (1)
-
unknown@example.com