From: Jeff Squyres Date: February 7, 2008 12:23:53 PM CST To: "Rolf Rabenseifner" Cc: "Mailing list for discussion of MPI 2.1" Subject: Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13 Reply-To: "Mailing list for discussion of MPI 2.1" 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 _______________________________________________ mpi-21 mailing list mpi-21@XXXXXXXXXXX http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21