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

[Jeff Squyres]

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