[mpi-21] Ballot 4 proposal: fix attribute example 4.13
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
>> 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
> 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
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
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
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".
More information about the Mpi-21