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

Jeff Squyres jsquyres at [hidden]
Mon May 18 10:24:57 CDT 2009 


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

More information about the Mpi-22 mailing list