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

Thu Feb 7 11:51:14 CST 2008

On Thu, 7 Feb 2008 12:22:27 -0500
 Jeff Squyres <jsquyres_at_[hidden]> wrote:
>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"?

Yes, "and" is what I wanted to say.

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

Normally, MPI never gives the application the right to change 
anything in a opaque object without calling an MPI routine.

C-routine MPI_xxx_get_attr is called with a handle to a opaque object
that has stored a Fortran integer-valued attribute.
IF we allow, that MPI_xxx_get_attr returns a pointer to foo
and foo contains the value of such fortran-integer-attribute,
AND IF we allow that a subsequent same call to MPI_xxx_get_attr returns
the same pointer to same foo, 
AND IF we allow that the application may change the value of foo,
THEN I would report:
  foo is part of the opaque object 
  and we allowed that the application has changed the value without
  calling MPI_xxx_set_attr.

If we do not want this, then there are two solutions:
- restrictive: to forbid changing the value from C directly;
- memory wasting: producing always a new foo in each call to MPI_xxx_get_attr.

Restrictive solution is also faster!

Nevertheless - ugly ;-)

Kind regards
Rolf

>> 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
>
>_______________________________________________
>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)