February 2008 - Mpi-21 - mailman3.cels.anl.gov

Review of MPI-2.1 combined document
by unknown＠example.com 23 Feb '08

23 Feb '08

The first draft of the combined document MPI 1.x plus MPI 2.0 is ready for review !!! All necessary files can be found via http://www.hlrs.de/mpi/mpi21/ The files are stored in a restricted directory to prohibit that search engines can find the drafts. Dear reviewer: Please print your chapter with colors (!) and check all merging decisions. The colors will help to identify MPI 1.1-1.3 (black), MPI-2.0 (magenta) and new text that was necessary for the merge (red). The review should be finished a few days before the March meeting. Please post your review results on mpi-21_at_[hidden] as reply to this mail. Please note, which chapter you reviewed. Please refer with all comments exactly to page and line numbers of - MPI 1.1, the official Postscript version - MPI 2.0, the official Postscript version - MPI 2.1, draft 2008-02-23 from http://www.hlrs.de/mpi/mpi21/ - and the merging plan 2008-02-23, that you can find at same directory If you detect a problem, it is necessary that you try to propose a solution in similar notation as used in the merging plan. I have finished all except the merging of the MPI-1 C++ bindings into the chapters' text, and except of merging the Annexes. The Ballots 1-4 are also not included. In the moment, you need to review only the "merging". Nothing more. If you detect errors in the original standards, then please go through normal procedure, i.e., through the MPI 2.1 and MPI 2.2 ballots. And now, thank you very much that you have registered to do a review (if you are on the list below, done in Jan.2008 meeting). Good luck. Best regards Rolf ---------------------------------------------------- Frontmatter: (I've done a new proposal for the abstract, please check) - Rusty Lusk, Bill Gropp Chap. 1: Introduction to MPI - Rusty Lusk, Bill Gropp, Karl Feind, Adam Moody Chap. 2: MPI-2 Terms and Conventions - Tony Skjellum, Bill Gropp, Richard Barrett Chap. 3: Point-to-Point Communication (incl. sections from MPI-2 Misc. + 8.9) - Rich Graham, Jespar Larsson Traeff, George Bosilca, Steve Poole, Kannan Narasimhan, David Solt, B. Gropp, Matt Koop Chap. 4: Collective Communication (incl. sections from MPI-2 Ext. Collect.) - Steven Ericsson-Zenith, Edgar Gabriel, Rajeev Thakur, Bill Gropp, Adam Moody, Georg Bosilca Chap. 5: Groups, Context, and Communicators (incl. sections from MPI-2 Ext.Col. + 8.8) - Steven Ericsson-Zenith, Edgar Gabriel, Bill Gropp, Georg Bosilca, Robert Blackmore Chap. 6: Process Topologies - Rusty Lusk, Bill Gropp, Richard Barrett Chap. 7: MPI Environmental Management (incl. sections from MPI-2 Misc.) - Rich Graham, Jespar Larsson Traeff, George Bosilca, Steve Poole, Kannan Narasimhan, David Solt, B. Gropp Chap. 8: Miscellany - Rich Graham, George Bosilca, Steve Poole, Kannan Narasimhan, B. Gropp Chap. 9: Process Creation and Management - Dries Kimpe, Rusty Lusk, Georg Bosilca, Bill Gropp, Kalem Karian Chap. 10: One-Sided Communication - Ericsson-Zenith, Jespar Larsson Traeff, Martin Schulz, Bill Gropp, Darius Buntinas Chap. 11: External Interfaces - Bronis de Supinski, Bill Gropp Chap. 12: I/O - Rajeev Thakur, Joachim Worringen, Bill Gropp Chap. 13: Language Bindings - Jeff Squyres, Steve Poole, Purushotham Bangalore, Bill Gropp, Erez Haba, Alexander Supalov Chap. 14: Profiling Interface - Bronis de Supinski, Bill Gropp, Jeff Brown Bibliography: (is done automatically) - Rusty Lusk, Bill Gropp Annex A: (this chapter is not yet done - therefore no review for this) - Jeff Squyres, Steve Poole, Purushotham Bangalore, Bill Gropp, Alexander Supalov Index: (is done automatically) - Rusty Lusk, Bill Gropp 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)

1 0

MPI 1.3 - errata from Ballot 3 and 4
by unknown＠example.com 10 Feb '08

10 Feb '08

Proposal: The following topics on http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… hould be marked with "To be included also in MPI 1.3" ----------------------------------------------------- Error in MPI_Scan Example Error in MPI-1, Example 3.12 Error in MPI-1, Example 3.12, continued Error in MPI-1, Example 3.13 Error in MPI-1, Examples 3.17 and 3.18 Error in MPI-1, Example 3.34 Use of strlen in MPI-1, chapter 3 Formatting error in discussion of persistent communication in MPI-1 Datatypes and MPI_PROBE MPI_Abort Error handler for multiple completions (if ready for March meeting) Not marked and therefore not included in MPI1.3 should be: ---------------------------------------------------------- Questions about Graph_create, Cart_create, and Cart_coords (not included, because it may require Impl.Effort, i.e. new version number 2.1) Error handler for multiple completions (if ready for March meeting) (not included or included, --- must be decided when proposal available) MPI_FINALIZE in MPI-2 (with spawn) (if ready for March meeting) (not included, because MPI&Threads is MPI 2) MPI_GET_PROCESSOR_NAME and Fortran (not included, because it may require Impl.Effort, i.e. new version number 2.1) Change "INOUT" to "IN" for MPI Handle Parameters in several routines (not included, because related to new MPI-2 Chapter 2 Terms&... Text) I hope I captured all currently proposed MPI-1.1 clarifications in Ballot 3 and 4. Best regards Rolf 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)

1 0

Re: [mpi-21] Ballot 4 - all proposal now on the web
by unknown＠example.com 07 Feb '08

07 Feb '08

Not best wording. I used - Selected for MPI 2.1 Ballot x if I would like to have it done in Ballot x but there is no proposal -- may be because there is no need, i.e., this topic is finished -- may be we are waiting for somebody who is writing the final proposal - Proposed for MPI 2.1 Ballot x means, somebody has written a proposal that ready for voting. At least in one case, the wrong word isused on the errata page. On March meeting, we can vote only on proposals that are really existing. I hope, somebody (not limited to discussion members) will write some of the pending proposals. Best regards Rolf PS: Selected for MPI 2.2 meant that the topic was on Bill's slide at Jan. 2008 meeting. On Thu, 07 Feb 2008 13:30:21 -0500 Terry Dontje <Terry.Dontje_at_[hidden]> wrote: >Can you clarify the difference between a topic marked "Selected for MPI >2.X Ballot Y" and "Proposed for MPI 2.X Ballot Y"? > >--td 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)

1 0

Re: [mpi-21] Ballot 4 - all proposal now on the web
by unknown＠example.com 07 Feb '08

07 Feb '08

Can you clarify the difference between a topic marked "Selected for MPI 2.X Ballot Y" and "Proposed for MPI 2.X Ballot Y"? --td "selected for Rolf Rabenseifner wrote: > Hi all interested in MPI 2.1! > > all proposals are now on the Web: > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… > > Please, check whether I've done something wrong. > > Although I've written the details of some of these proposals, > I try to be the moderator of the discussion. > In some cases, when I saw that several options are possible, > and none of these seemed to me technically obvious or perfect, > I've put all these options on the web page to allow that the > MPI Forum can make those decisions at the March meeting. > > Please check, whether I've done something wrong or whether > I have to add an additional alternative proposal > (in this case, please write the proposal with all necessary > details (as text) that I can make a cut&paste to the web page > plus additional HTML formatting). > > Please check for the RED flag Ballot 4 topics > and help that the missing proposals are written. > > Best regards > Rolf > > > 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 >

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

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

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

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/discus… >>> >>> 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/discus… >>>> >>>> >>>> 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)

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

Terry and I further noticed that there appears to be another minor problem in example 4.13. So here's an addendum to the proposal: MPI-2:4.12.7 p59 line 1 reads: int *p But should read MPI_Aint *p Rationale: The value that is set from fortran is an INTEGER(kind=MPI_ADDRESS_KIND). Hence, to dereference it properly, the corresponding C pointer type needs to be an (MPI_Aint*), not (int*). On Feb 7, 2008, at 12:04 PM, Terry Dontje wrote: > After talking with Jeff and reading the spec further I retract my > concern because the spec does explicitly cover my concern in the > verbage > above example 4.13. > > --td > > 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/discus… >> >> >> 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/discus… >>> >>> >>> 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 -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

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"? > 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? > 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/discus… >> >> 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/discus… >>> >>> >>> 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

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

After talking with Jeff and reading the spec further I retract my concern because the spec does explicitly cover my concern in the verbage above example 4.13. --td 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/discus… > > > 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/discus… >> >> >> 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. >> > >

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

Yes, we should make the following proposal (A) 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. Additional proposal (B): Add at the end of the previous text: The application must not change this integer valued attribute at the returned address. 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/discus… > >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/discus… >> >> >> 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)

1 0