[mpi-21] Ballot 4 proposal: fix attribute example 4.13

[Rolf Rabenseifner]

Yes, we should make the following proposal (A)

MPI 2.0 Sect.4.12.7 Attributes, page 58 lines 14-16 read:

   When an integer valued attribute is accessed from C or C++, 
   then MPI xxx get attr will return the address of (a pointer to)
   the integer valued attribute.

but should read:

   When an integer valued attribute is accessed from C or C++, 
   then MPI xxx get attr will return the address of (a pointer to)
   the integer valued attribute; the address is only valid as long
   the attribute is not changed or the object on which the attribute
   is cached is not freed. 

Additional proposal (B): Add at the end of the previous text:
   The application must not change this integer valued attribute 
   at the returned address.
   
Comment:
I know, that this proposal has limited value in multithreaded 
execution when one thread tries to get an attribute and another
thread is modifying it, but this must be handled by locks on 
application level.

Proposal A requires that for each call to C routine MPI_xxx_get_attr()
with a integer-valued attribute argument, a new location is
produced in the object where the attribute is copied and from
which the address is returned.

Proposal A+B allows that the address of the originally stored 
integer is returned by MPI_xxx_get_attr().

Therefore A+B requires smallest implementation effort.
   
Is this a good solution?

Best regards
Rolf

On Thu, 07 Feb 2008 10:49:12 -0500
 Terry Dontje <Terry.Dontje_at_[hidden]> wrote:
>Sorry I didn't send this out sooner but in reading the discussion for 
>the errata item "Interlaguage use of Attributes" I think the below 
>proposal has a potential hole that never was resolved in the mail 
>discussion in:
>http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/getattr/
>
>The specific hole pointed out by Nick Nevin in the following paragraph 
>from the email discussion:
>
>This might work for predefined attributes where the address can
>point to the integer value in static storage, but won't work for
>attributes set by the user in Fortran code.  If you store a pointer
>to the integer as the attribute it may point to a temporary which
>might no longer exist when you try and access it later.
>
>
>So I think relying on the address passed in for the attribute as opposed 
>to the value could cause some
>issues with Fortran.
>
>--td
>Jeff Squyres wrote:
>> Per 
>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/, 
>> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of 
>> Attributes in C and Fortran)".  I believe that this errata item 
>> supersedes the errata item "Interlanguage use of Attributes".
>>
>> See the mail discussing:
>>
>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/attrcandf/ 
>>
>>
>> Proposal:
>>
>> Change MPI-2:4.12, p58:36 from:
>>   IF (val.NE.5) THEN CALL ERROR
>> to
>>   IF (val.NE.address_of_i) THEN CALL ERROR
>>
>> Rationale:
>>
>> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is 
>> set by C, retrieving it in Fortran will obtain the address of the 
>> attribute.
>>
>> See the mails for more discussion, including an exhaustive list of 
>> what happens for each of the 9 possibilities of setting and getting 
>> attribute values between the different languages.
>>
>
>_______________________________________________
>mpi-21 mailing list
>mpi-21_at_[hidden]
>http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21

Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden]
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)