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

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

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)