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

[William Gropp]

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