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

19 May 2009


      MPICH2 passes the value of the extra_state that was saved in the  
internal storage to the callback routine, which is case 2 (the copy is  
implicit as the value is passed to the routine and C semantics ensures  
that the value isn't changed).

Bill

On May 18, 2009, at 10:24 AM, Jeff Squyres wrote:
...
I'm most curious to know what current MPI implementations do in this
scenario.
On May 14, 2009, at 1:05 PM, Jeff Squyres wrote:
...
Another question about this issue...
Since all fortran values are passed by reference, does the MPI care
if the callback function changes the EXTRA_STATE value?  I see 2
choices:
1. The MPI copies the value of extra_state when MPI_*_CREATE_KEVAL
is invoked to internal storage.  This internal storage is passed to
all the callbacks when invoked.  If any of the callbacks change the
value, then subsequent invocations of the callback get the changed
value.
2. The MPI copies the value of extra_state when MPI_*_CREATE_KEVAL
is invoked to internal storage.  This internal storage is copied any
time a callback is invoked; the copy is passed to the callback (and
freed when the callback returns).  In this way, the same EXTRA_STATE
value that was originally passed to the keyval constructor will
always be passed to any callbacks.
What do current MPI implementations do?
OMPI's development trunk has been updated to do #1; I'm wondering if
it should do #2.
On Apr 17, 2009, at 10:21 AM, Jeff Squyres (jsquyres) wrote:
...
Ok, I'll file an MPI-3 ticket for this.
(for everyone else on the 2.2 list wondering why you just got
blitzkrieged with a whole pile of emails on this topic: the
listserver
sent all these mails to moderation because of the lengthy CC list.
IU
just approved all the mails to go through this morning)
On Apr 17, 2009, at 9:40 AM, William Gropp wrote:
...
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
--
Jeff Squyres
Cisco Systems
_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
-- 
Jeff Squyres
Cisco Systems
_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
-- 
Jeff Squyres
Cisco Systems
_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
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

unknown＠example.com

tags

participants (1)