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

[Jeff Squyres]

On Feb 7, 2008, at 11:28 AM, Rolf Rabenseifner wrote:

> 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.

Shouldn't the "or" in the last phrase be "and"?

> Additional proposal (B): Add at the end of the previous text:
>   The application must not change this integer valued attribute
>   at the returned address.

I had to think about this quite a bit before I "got it" -- you're  
saying that when an integer-valued attribute is set (from fortran),  
the MPI implementation must be caching the value internally and then  
returning a pointer to that internally cached value.  Hence, the  
address is only valid as long as the MPI object is valid.

However, I'm not sure about the requirement of not changing the value  
(for integer-valued attributes).  If you MPI_xxx_get_attr from C and  
change the value, it'll be changed for any subsequent MPI_xxx_get_attr  
calls from C or Fortran.  However, if you MPI_xxx_get_attr from  
Fortran and change the value, the next call to MPI_xxx_get_attr will  
have the original value.

Are you just trying to avoid this disparity?

> 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)
> _______________________________________________
> mpi-21 mailing list
> mpi-21_at_[hidden]
> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21


-- 
Jeff Squyres
Cisco Systems