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

[Jeff Squyres]

On Feb 7, 2008, at 12:51 PM, Rolf Rabenseifner wrote:

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

Ah, I can see this rationale.  Good point.  It might be helpful to  
have some synopsis of your above text should be part of a "Rationale"  
block in the official text, because that's not immediately obvious.

What I have difficulty resolving, though, is that this would be an  
asymmetrical exception:

1. set attribute in fortran, get attribute in fortran: allowed to change
2. set attribute in fortran, get attribute in C: *NOT* allowed to change
3. set attribute in C, get attribute in C: allowed to change
4. set attribute in C, get attribute in fortran: allowed to change

I can see your rationale; it's just that this asymmetry makes me...  
uncomfortable.  Indeed, case 2 is the only case where the life of the  
MPI object is related to the life of the attribute.  That's just weird  
to me.

But I could probably be convinced that this is ok -- after all, who  
really cares about attributes!  ;-)  (e.g., the set-in-C-get-in- 
fortran case is almost useless...)

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

The memory wasting solution is no good -- we'd either have to say that  
the caller is reponsible for free()'ing the returned pointer or accept  
a memory leak, because there's no way for the caller to give the  
pointer back to MPI and say "I'm done with this".


-- 
Jeff Squyres
Cisco Systems