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

Jeff Squyres jsquyres at [hidden]
Thu Feb 7 12:23:53 CST 2008

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

More information about the Mpi-21 mailing list