From rabenseifner@XXXXXXX Thu Feb 7 12:06:43 2008 X-Virus-Scanned: by amavisd-new at hydra.rus.uni-stuttgart.de X-Virus-Scanned: by mbox.uni-stuttgart.de From: "Rolf Rabenseifner" To: "Mailing list for discussion of MPI 2.1" X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Thu, 07 Feb 2008 18:51:14 +0100 In-Reply-To: References: <0367FBAD-2ACE-4BBD-99D8-9D2FB6E0F92B@XXXXXXXXX> <47AB2878.8060102@XXXXXXX> MIME-Version: 1.0 X-Spam-Details: rule=tag_notspam policy=tag score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0801230000 definitions=main-0802070049 X-Spam-OrigSender: rusrabe@XXXXXXXXXXXXXXXXXXXX X-Spam-Bar: Subject: Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13 X-BeenThere: mpi-21@XXXXXXXXXXX X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Mailing list for discussion of MPI 2.1" List-Id: "Mailing list for discussion of MPI 2.1" List-Archive: List-Post: List-Help: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpi-21-bounces@XXXXXXXXXXX Errors-To: mpi-21-bounces@XXXXXXXXXXX X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailgw.mcs.anl.gov On Thu, 7 Feb 2008 12:22:27 -0500 Jeff Squyres 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 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/getattr/ >>> >>> 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/attrcandf/ >>>> >>>> >>>> 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@XXXXXXXXXXX >>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@XXXXXXX >> 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@XXXXXXXXXXX >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-21 mailing list >mpi-21@XXXXXXXXXXX >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@XXXXXXX 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@XXXXXXXXXXX http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21