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

[Jeff Squyres]

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