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

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 23 Jan '08

23 Jan '08

On Jan 23, 2008, at 7:16 AM, Jeff Squyres wrote: > This would be in accordance with the existing MPI-1:2.2 language, > and therefore (I think) redundant. > > However, see my summary e-mail from last night about the C++ > bindings -- I am wondering why the special case for [IN]OUT handle > arguments exists to begin with (that a parameter is OUT if the > underlying MPI object is changed when the handle is not). I just now saw your other mail about all of MPI-1:2 being deprecated in favor of MPI-2:2 -- you're right; I followed up in that thread. > > > > On Jan 22, 2008, at 11:29 AM, Rolf Rabenseifner wrote: > >> An alternative-proposal would be to add a clarifying sentence in >> Terms and Conventions, MPI-2.0 Sect. 2.5.1, page 9, line 7: >> Handle arguments can be marked at INOUT to indicate that the handle >> itself may be changed by the routine (e.g., in MPI_TYPE_COMMIT), >> or to indicate that the object referenced by the handle may be >> changed but the handle itself is kept unchanged >> (e.g., MPI_TYPE_SET_NAME). >> >> Rolf Rabenseifner >> >> >> On Mon, 21 Jan 2008 09:42:02 -0500 >> Jeff Squyres <jsquyres_at_[hidden]> wrote: >>> This is not already on Bill's errata page. >>> >>> Proposal: change the INOUT designation of the MPI handle >>> parameters in several MPI-2 functions to be IN, because the >>> values of the handles are not changing. Only the underlying MPI >>> objects are changing. The C bindings for each of these functions >>> do *not* pass the MPI handle by reference, therefore disallowing >>> the possibility of these parameters actually being INOUT. By the >>> same argument, the C++ methods for these functions should be >>> const since the C++ object invoking the method will not be changed. >>> >>> The functions in question are: >>> >>> MPI_*_SET_NAME for communicators, datatypes, windows >>> MPI_*_SET_ATTR for communicators, datatypes, windows >>> MPI_*_SET_ERRHANDLER for communicators, files, windows >>> >>> Locations of specific text to be changed (INOUT -> IN, add "const" >>> to C ++ methods): >>> >>> MPI_COMM_SET_NAME: MPI-2:8.4, p177:35,44 >>> MPI-2:A.8.5, p336:28 >>> MPI_TYPE_SET_NAME: MPI-2:8.4, p179:41, p180:2 >>> MPI-2:A.8.5, p337:2 >>> MPI_WIN_SET_NAME: MPI-2:8.4, p181:25,35 >>> MPI-2:A.8.5, p337:36 >>> >>> MPI_COMM_SET_ATTR: MPI-2:8.8.1, p201:6,17 >>> MPI-2:A.8.5, p336:27 >>> MPI_WIN_SET_ATTR: MPI-2:8.8.2, p204:2,12 >>> MPI-2:A.8.5, p337:35 >>> MPI_TYPE_SET_ATTR: MPI-2:8.8.3, p206:26,37 >>> MPI-2:A.8.5, p337:1 >>> >>> MPI_COMM_SET_ERRHANDLER: MPI-2:4.13.1, p62:35,43 >>> MPI-2:A.8.1, p331:38 >>> MPI_WIN_SET_ERRHANDLER: MPI-2:4.13.2, p64:2,10 >>> MPI-2:A.8.1, p333:13 >>> MPI_FILE_SET_ERRHANDLER: MPI-2:4.13.3, p65:14,22 >>> MPI-2:A.8.1, p332:34 >>> >>> NOTE: The "const" issues of this proposal will be dependent upon a >>> 2nd proposal about re-instituting the "const" on MPI predefined >>> handles that was removed in ballot 2. >>> >>> -- >>> Jeff Squyres >>> Cisco Systems >>> >> >> >> >> 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) >> > > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] C++ predefined MPI handles, const, IN/INOUT/OUT, etc.
by unknown＠example.com 23 Jan '08

23 Jan '08

On Jan 23, 2008, at 4:33 AM, Rolf Rabenseifner wrote: > you are referencing to MPI-1.1, Sect. 2.2. > The full Chapter 2 of MPI-1.1 is deprecated and substituted by > the full Chapter 2 of MPI-2.0. > In the substituting MPI-2.0 Sect. 2.3, there exist the > following new paragraph: > "MPIs use of IN, OUT and INOUT is intended to indicate to the user > how an argument is to be used, but does not provide a rigorous > classification that can be translated directly into all language > bindings (e.g., INTENT in Fortran 90 bindings or const in C > bindings). > For instance, the constant MPI BOTTOM can usually be passed to OUT > buffer arguments. Similarly, MPI STATUS IGNORE can be passed as the > OUT status argument." Ok; I missed that text -- thanks. So replace every instance of "MPI-1:2.2" in my original text with "MPI-2:2.3", where exactly the same special case definition exists. > My comments and alternative-proposal from Tue, 22 Jan 2008 17:29:51 > was about this paragraph (updated text to reflect also the "IN" of > "INOUT"): > >> An alternative-proposal would be to add a clarifying sentence in >> Terms and Conventions, MPI-2.0 Sect. 2.5.1, page 9, line 7: >> Handle arguments can be marked at INOUT to indicate that the handle >> itself may be changed by the routine (e.g., in MPI_TYPE_COMMIT), >> or to indicate that the object referenced by the handle > already exists and >> may be changed but the handle itself is kept unchanged >> (e.g., MPI_TYPE_SET_NAME). Per the text in my summary mail (below), I think that that would be exactly the wrong thing to say (and it would be redundant with MPI-2:2.3). My point is that this special case definition for [IN]OUT should go away if no one can specify the reason why it's there. Indeed, the text that Rolf cites in MPI-2:2.3 both strengthens and weakens my arguments: - STRENGTHEN: "MPI's use of IN, OUT and INOUT is intended to indicate to the user how an argument is to be used..." - WEAKEN: "...but does not provide a rigorous classification that can be translated directly into all language bindings (e.g., INTENT in Fortran 90 bindings or const in C++ bindings)." However, the latter part of the sentence can be ignored because it says that IN/OUT/INOUT do not *have* to be used as a rigorous classification. This clears the way for the 3 proposals that I sent the other day: 1. Make all the SET_NAME and SET_ERRHANDLER functions have IN MPI handle arguments (vs. INOUT) -- by the new sentence in MPI-2:2.3, the value of the argument is not being changed by the function call (per the already-existing C bindings). So these are now clearly IN arguments. Also, make the C++ bindings for these functions be const. 2. Restore the "const" to the C++ MPI predefined handles that were removed in ballot 2. 3. Make MPI::COMM_WORLD and MPI::COMM_SELF be const. Additionally, I would like to request/motion/whatever that the "remove const from more C++ constants" item be withdrawn from what was supposed to be on ballot 3 but got moved to ballot 4. *** The end goal is to make all the MPI C++ constants be "const" (except MPI::BOTTOM, as we discussed in Chicago) and have all the SET_NAME and SET_ERRHANDLER methods be const. Thanks. - Jeff > Best regards > Rolf > > > On Tue, 22 Jan 2008 20:07:05 -0500 > Jeff Squyres <jsquyres_at_[hidden]> wrote: >> The 3 proposals that I sent about C++ issues are both intertwined and >> represent a very complex set of issues. >> >> Shorter version >> =============== >> >> Does anyone know/remember why the "special case" for the definition >> of >> OUT parameters exists in MPI-1:2.2? >> >> I ask because the C++ bindings were modeled off the IN/OUT/INOUT >> designations of the language neutral bindings. MPI_COMM_SET_NAME >> (and >> others) use the "special case" definition of the [IN]OUT designation >> for the MPI communicator handle parameter. Two facts indicate that >> we >> should either override this INOUT designation for the C++ binding >> (and >> therefore make the method const) and/or revisit the "special case" >> language in MPI-1:2.2: >> >> 1. The C binding does not allow the implementation to change the >> handle value >> 2. The following is a valid MPI code: >> >> MPI::Intracomm cxx_comm = MPI::COMM_WORLD; >> cxx_comm.Set_name("foo"); >> MPI::COMM_WORLD.Get_name(name, len); >> cout << name << endl; >> >> The output will be "foo" even though we set the name on cxx_comm >> and retrieved it from MPI::COMM_WORLD ***because the state changed on >> the underlying MPI object, not the upper-level handles*** (the same >> is >> true for error handlers). >> >> Hence, the Set_name() method should be const because the MPI handle >> will not (and cannot) change. Similar arguments apply to keeping the >> MPI predefined C++ handles as "const" (MPI::INT, etc.) -- their >> values >> must never change during execution. It then follows that unless >> there >> is a good reason for the "special case" language in MPI-1:2.2, it >> should be removed. >> >> Longer version / more details >> ============================= >> >> At the heart of the issue seems to be text from MPI-1:2.2 about the >> definition of IN, OUT, and INOUT parameters to MPI functions. This >> text was used to guide many of the decisions about the C++ bindings, >> such as the const-ness (or not) of C++ methods and MPI predefined C++ >> handles. The text states: >> >> ----- >> * the call uses but does not update an argument marked IN >> * the call may update an argument marked OUT >> * the call both uses and updates an argument marked INOUT >> >> There is one special case -- if an argument is a handle to an opaque >> object (these terms are defined in Section 2.4.1) and the object is >> updated by the procedure call, then the argument is marked OUT. It >> is >> marked this way even though the handle itself is not modified -- we >> use the OUT attribute to denote that what the handle _references_ is >> updated. >> ----- >> >> The special case for the OUT definition is important because the C++ >> bindings were created to mimic the IN, OUT, and INOUT behavior in a >> language that is stricter than C and Fortran: C++ will fail to >> compile >> if an application violates the defined semantics (which is a good >> thing). >> >> *** The big question: does anyone know/remember why this special case >> *** for the "OUT" definition exists? >> >> The special case seems to imply that *explicit* changes to MPI >> objects >> should be marked as an [IN]OUT parameter (e.g., SET_NAME and >> SET_ERRHANDLER). Apparently, *implicit* changes to the underlying >> MPI >> object (such as MPI_ISEND) do not count / should be IN (i.e., many >> MPI >> implementation *do* change the state either on the communicator or >> something related to the communicator when a send or receive is >> initiated, even though the communicator is an IN argument). >> >> But remember that MPI clearly states that the handle is separate from >> the underlying MPI object. So why does the binding care if the back- >> end object is updated? (regardless of whether the change to the >> object is explicit or implicit) >> >> For example, the language-neutral binding for MPI_COMM_SET_NAME has >> the communicator as an INOUT argument. This clearly falls within the >> "special case" definition because the function semantics explicitly >> change state on the underlying MPI object. >> >> But note that the C binding is "int MPI_Comm_set_name(MPI_Comm >> comm, ...)". Notice that the comm is passed by value, not by >> reference. So even though the language neutral binding called that >> parameter INOUT, it's not possible for the MPI implementation to >> change the value of the handle. >> >> My claim is that if we want to ensure that the C++ bindings match the >> C bindings (i.e., that the implementation cannot change the value of >> the MPI handle), then the method should be const (i.e., >> cxx_comm.Set_name(...)) *because the handle value will not, and >> ***cannot***, change*. >> >> Simply put: regardless of language or implementation, MPI handles >> must >> have true handle semantics. For example: >> >> MPI::Intracomm cxx_comm = MPI::COMM_WORLD; >> cxx_comm.Set_name("C++ r00l3z!"); >> >> MPI::COMM_WORLD.Get_name(name, len); >> cout << name << endl; >> >> The above will output "C++ r00l3z!" because cxx_comm and >> MPI::COMM_WORLD are handles referring to the same underlying >> communicator. Hence, the only state that the handles have is >> whatever >> refers to their back-end MPI object. Having Set_name() be const >> keeps the *handle* const, not the underlying MPI object. >> >> Tying this all together: >> >> 1. cxx_comm.Set_name() *cannot* change state on the cxx_comm handle >> because cxx_comm.Get_name() and MPI::COMM_WORLD.Get_name() must >> return >> the same results (the same is true for error handlers). Hence, >> regardless of the implementation of the C++ bindings, the handle >> value >> cannot change. Therefore, this method (and all the others like it) >> should be const. >> >> 2. As a related issue, if no one can remember why the "special case" >> exists for OUT, then I think we should remove this text and then >> change all those INOUT parameters for the functions I cited in my >> earlier proposal to IN. This would make the C++ bindings consistent >> with the IN/OUT/INOUT specifications of the language-neutral >> bindings. >> >> 3. All the MPI C++ predefined handles should be const for many of the >> same reasons. Regardless of what happens to the underlying MPI >> object, the value of the handle cannot ever change. This is >> guaranteed by MPI-2:2.5.4 pages 10 lines 38-41: >> >> "All named constants, with the exceptions noted below for Fortran, >> can >> be used in initialization expressions or assignments. These >> constants >> do not change values during execution. Opaque objects accessed by >> constant handles are defined and do not change value between MPI >> initialization MPI_INIT and MPI completion MPI_FINALIZE." >> >> Hence, they should all be "const". >> >> ----- >> >> In short: C++ gives us stronger protections to ensure that >> applications don't shoot themselves in the foot. If the MPI >> predefined handles are const, then statements like "MPI::INT = >> my_dtype;" will fail to compile. This is a Good Thing. >> >> The original C++ bindings tried to take advantage of const, but >> missed >> a few points. Ballot two and one of the items in ballot 3 >> incorrectly >> tried to fix these points by removing const in several places. That >> "fixes" the problem, but removes many of the good qualities that we >> can get in C++ with "const". So let's fix the real problem and leave >> "const" in the C++ bindings. >> >> Are you confused yet? :-) >> >> -- >> 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) > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 23 Jan '08

23 Jan '08

This would be in accordance with the existing MPI-1:2.2 language, and therefore (I think) redundant. However, see my summary e-mail from last night about the C++ bindings -- I am wondering why the special case for [IN]OUT handle arguments exists to begin with (that a parameter is OUT if the underlying MPI object is changed when the handle is not). On Jan 22, 2008, at 11:29 AM, Rolf Rabenseifner wrote: > An alternative-proposal would be to add a clarifying sentence in > Terms and Conventions, MPI-2.0 Sect. 2.5.1, page 9, line 7: > Handle arguments can be marked at INOUT to indicate that the handle > itself may be changed by the routine (e.g., in MPI_TYPE_COMMIT), > or to indicate that the object referenced by the handle may be > changed but the handle itself is kept unchanged > (e.g., MPI_TYPE_SET_NAME). > > Rolf Rabenseifner > > > On Mon, 21 Jan 2008 09:42:02 -0500 > Jeff Squyres <jsquyres_at_[hidden]> wrote: >> This is not already on Bill's errata page. >> >> Proposal: change the INOUT designation of the MPI handle parameters >> in several MPI-2 functions to be IN, because the values of the >> handles are not changing. Only the underlying MPI objects are >> changing. The C bindings for each of these functions do *not* >> pass the MPI handle by reference, therefore disallowing the >> possibility of these parameters actually being INOUT. By the same >> argument, the C++ methods for these functions should be const >> since the C++ object invoking the method will not be changed. >> >> The functions in question are: >> >> MPI_*_SET_NAME for communicators, datatypes, windows >> MPI_*_SET_ATTR for communicators, datatypes, windows >> MPI_*_SET_ERRHANDLER for communicators, files, windows >> >> Locations of specific text to be changed (INOUT -> IN, add "const" >> to C ++ methods): >> >> MPI_COMM_SET_NAME: MPI-2:8.4, p177:35,44 >> MPI-2:A.8.5, p336:28 >> MPI_TYPE_SET_NAME: MPI-2:8.4, p179:41, p180:2 >> MPI-2:A.8.5, p337:2 >> MPI_WIN_SET_NAME: MPI-2:8.4, p181:25,35 >> MPI-2:A.8.5, p337:36 >> >> MPI_COMM_SET_ATTR: MPI-2:8.8.1, p201:6,17 >> MPI-2:A.8.5, p336:27 >> MPI_WIN_SET_ATTR: MPI-2:8.8.2, p204:2,12 >> MPI-2:A.8.5, p337:35 >> MPI_TYPE_SET_ATTR: MPI-2:8.8.3, p206:26,37 >> MPI-2:A.8.5, p337:1 >> >> MPI_COMM_SET_ERRHANDLER: MPI-2:4.13.1, p62:35,43 >> MPI-2:A.8.1, p331:38 >> MPI_WIN_SET_ERRHANDLER: MPI-2:4.13.2, p64:2,10 >> MPI-2:A.8.1, p333:13 >> MPI_FILE_SET_ERRHANDLER: MPI-2:4.13.3, p65:14,22 >> MPI-2:A.8.1, p332:34 >> >> NOTE: The "const" issues of this proposal will be dependent upon a >> 2nd proposal about re-instituting the "const" on MPI predefined >> handles that was removed in ballot 2. >> >> -- >> Jeff Squyres >> Cisco Systems >> > > > > 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) > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] C++ predefined MPI handles, const, IN/INOUT/OUT, etc.
by unknown＠example.com 23 Jan '08

23 Jan '08

Jeff, you are referencing to MPI-1.1, Sect. 2.2. The full Chapter 2 of MPI-1.1 is deprecated and substituted by the full Chapter 2 of MPI-2.0. In the substituting MPI-2.0 Sect. 2.3, there exist the following new paragraph: "MPIs use of IN, OUT and INOUT is intended to indicate to the user how an argument is to be used, but does not provide a rigorous classification that can be translated directly into all language bindings (e.g., INTENT in Fortran 90 bindings or const in C bindings). For instance, the constant MPI BOTTOM can usually be passed to OUT buffer arguments. Similarly, MPI STATUS IGNORE can be passed as the OUT status argument." My comments and alternative-proposal from Tue, 22 Jan 2008 17:29:51 was about this paragraph (updated text to reflect also the "IN" of "INOUT"): >An alternative-proposal would be to add a clarifying sentence in >Terms and Conventions, MPI-2.0 Sect. 2.5.1, page 9, line 7: > Handle arguments can be marked at INOUT to indicate that the handle > itself may be changed by the routine (e.g., in MPI_TYPE_COMMIT), > or to indicate that the object referenced by the handle already exists and > may be changed but the handle itself is kept unchanged > (e.g., MPI_TYPE_SET_NAME). Best regards Rolf On Tue, 22 Jan 2008 20:07:05 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote: >The 3 proposals that I sent about C++ issues are both intertwined and >represent a very complex set of issues. > >Shorter version >=============== > >Does anyone know/remember why the "special case" for the definition of >OUT parameters exists in MPI-1:2.2? > >I ask because the C++ bindings were modeled off the IN/OUT/INOUT >designations of the language neutral bindings. MPI_COMM_SET_NAME (and >others) use the "special case" definition of the [IN]OUT designation >for the MPI communicator handle parameter. Two facts indicate that we >should either override this INOUT designation for the C++ binding (and >therefore make the method const) and/or revisit the "special case" >language in MPI-1:2.2: > >1. The C binding does not allow the implementation to change the >handle value >2. The following is a valid MPI code: > > MPI::Intracomm cxx_comm = MPI::COMM_WORLD; > cxx_comm.Set_name("foo"); > MPI::COMM_WORLD.Get_name(name, len); > cout << name << endl; > > The output will be "foo" even though we set the name on cxx_comm >and retrieved it from MPI::COMM_WORLD ***because the state changed on >the underlying MPI object, not the upper-level handles*** (the same is >true for error handlers). > >Hence, the Set_name() method should be const because the MPI handle >will not (and cannot) change. Similar arguments apply to keeping the >MPI predefined C++ handles as "const" (MPI::INT, etc.) -- their values >must never change during execution. It then follows that unless there >is a good reason for the "special case" language in MPI-1:2.2, it >should be removed. > >Longer version / more details >============================= > >At the heart of the issue seems to be text from MPI-1:2.2 about the >definition of IN, OUT, and INOUT parameters to MPI functions. This >text was used to guide many of the decisions about the C++ bindings, >such as the const-ness (or not) of C++ methods and MPI predefined C++ >handles. The text states: > >----- > * the call uses but does not update an argument marked IN > * the call may update an argument marked OUT > * the call both uses and updates an argument marked INOUT > >There is one special case -- if an argument is a handle to an opaque >object (these terms are defined in Section 2.4.1) and the object is >updated by the procedure call, then the argument is marked OUT. It is >marked this way even though the handle itself is not modified -- we >use the OUT attribute to denote that what the handle _references_ is >updated. >----- > >The special case for the OUT definition is important because the C++ >bindings were created to mimic the IN, OUT, and INOUT behavior in a >language that is stricter than C and Fortran: C++ will fail to compile >if an application violates the defined semantics (which is a good >thing). > >*** The big question: does anyone know/remember why this special case >*** for the "OUT" definition exists? > >The special case seems to imply that *explicit* changes to MPI objects >should be marked as an [IN]OUT parameter (e.g., SET_NAME and >SET_ERRHANDLER). Apparently, *implicit* changes to the underlying MPI >object (such as MPI_ISEND) do not count / should be IN (i.e., many MPI >implementation *do* change the state either on the communicator or >something related to the communicator when a send or receive is >initiated, even though the communicator is an IN argument). > >But remember that MPI clearly states that the handle is separate from >the underlying MPI object. So why does the binding care if the back- >end object is updated? (regardless of whether the change to the >object is explicit or implicit) > >For example, the language-neutral binding for MPI_COMM_SET_NAME has >the communicator as an INOUT argument. This clearly falls within the >"special case" definition because the function semantics explicitly >change state on the underlying MPI object. > >But note that the C binding is "int MPI_Comm_set_name(MPI_Comm >comm, ...)". Notice that the comm is passed by value, not by >reference. So even though the language neutral binding called that >parameter INOUT, it's not possible for the MPI implementation to >change the value of the handle. > >My claim is that if we want to ensure that the C++ bindings match the >C bindings (i.e., that the implementation cannot change the value of >the MPI handle), then the method should be const (i.e., >cxx_comm.Set_name(...)) *because the handle value will not, and >***cannot***, change*. > >Simply put: regardless of language or implementation, MPI handles must >have true handle semantics. For example: > > MPI::Intracomm cxx_comm = MPI::COMM_WORLD; > cxx_comm.Set_name("C++ r00l3z!"); > > MPI::COMM_WORLD.Get_name(name, len); > cout << name << endl; > >The above will output "C++ r00l3z!" because cxx_comm and >MPI::COMM_WORLD are handles referring to the same underlying >communicator. Hence, the only state that the handles have is whatever >refers to their back-end MPI object. Having Set_name() be const >keeps the *handle* const, not the underlying MPI object. > >Tying this all together: > >1. cxx_comm.Set_name() *cannot* change state on the cxx_comm handle >because cxx_comm.Get_name() and MPI::COMM_WORLD.Get_name() must return >the same results (the same is true for error handlers). Hence, >regardless of the implementation of the C++ bindings, the handle value >cannot change. Therefore, this method (and all the others like it) >should be const. > >2. As a related issue, if no one can remember why the "special case" >exists for OUT, then I think we should remove this text and then >change all those INOUT parameters for the functions I cited in my >earlier proposal to IN. This would make the C++ bindings consistent >with the IN/OUT/INOUT specifications of the language-neutral bindings. > >3. All the MPI C++ predefined handles should be const for many of the >same reasons. Regardless of what happens to the underlying MPI >object, the value of the handle cannot ever change. This is >guaranteed by MPI-2:2.5.4 pages 10 lines 38-41: > >"All named constants, with the exceptions noted below for Fortran, can >be used in initialization expressions or assignments. These constants >do not change values during execution. Opaque objects accessed by >constant handles are defined and do not change value between MPI >initialization MPI_INIT and MPI completion MPI_FINALIZE." > >Hence, they should all be "const". > >----- > >In short: C++ gives us stronger protections to ensure that >applications don't shoot themselves in the foot. If the MPI >predefined handles are const, then statements like "MPI::INT = >my_dtype;" will fail to compile. This is a Good Thing. > >The original C++ bindings tried to take advantage of const, but missed >a few points. Ballot two and one of the items in ballot 3 incorrectly >tried to fix these points by removing const in several places. That >"fixes" the problem, but removes many of the good qualities that we >can get in C++ with "const". So let's fix the real problem and leave >"const" in the C++ bindings. > >Are you confused yet? :-) > >-- >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

C++ predefined MPI handles, const, IN/INOUT/OUT, etc.
by unknown＠example.com 22 Jan '08

22 Jan '08

The 3 proposals that I sent about C++ issues are both intertwined and represent a very complex set of issues. Shorter version =============== Does anyone know/remember why the "special case" for the definition of OUT parameters exists in MPI-1:2.2? I ask because the C++ bindings were modeled off the IN/OUT/INOUT designations of the language neutral bindings. MPI_COMM_SET_NAME (and others) use the "special case" definition of the [IN]OUT designation for the MPI communicator handle parameter. Two facts indicate that we should either override this INOUT designation for the C++ binding (and therefore make the method const) and/or revisit the "special case" language in MPI-1:2.2: 1. The C binding does not allow the implementation to change the handle value 2. The following is a valid MPI code: MPI::Intracomm cxx_comm = MPI::COMM_WORLD; cxx_comm.Set_name("foo"); MPI::COMM_WORLD.Get_name(name, len); cout << name << endl; The output will be "foo" even though we set the name on cxx_comm and retrieved it from MPI::COMM_WORLD ***because the state changed on the underlying MPI object, not the upper-level handles*** (the same is true for error handlers). Hence, the Set_name() method should be const because the MPI handle will not (and cannot) change. Similar arguments apply to keeping the MPI predefined C++ handles as "const" (MPI::INT, etc.) -- their values must never change during execution. It then follows that unless there is a good reason for the "special case" language in MPI-1:2.2, it should be removed. Longer version / more details ============================= At the heart of the issue seems to be text from MPI-1:2.2 about the definition of IN, OUT, and INOUT parameters to MPI functions. This text was used to guide many of the decisions about the C++ bindings, such as the const-ness (or not) of C++ methods and MPI predefined C++ handles. The text states: ----- * the call uses but does not update an argument marked IN * the call may update an argument marked OUT * the call both uses and updates an argument marked INOUT There is one special case -- if an argument is a handle to an opaque object (these terms are defined in Section 2.4.1) and the object is updated by the procedure call, then the argument is marked OUT. It is marked this way even though the handle itself is not modified -- we use the OUT attribute to denote that what the handle _references_ is updated. ----- The special case for the OUT definition is important because the C++ bindings were created to mimic the IN, OUT, and INOUT behavior in a language that is stricter than C and Fortran: C++ will fail to compile if an application violates the defined semantics (which is a good thing). *** The big question: does anyone know/remember why this special case *** for the "OUT" definition exists? The special case seems to imply that *explicit* changes to MPI objects should be marked as an [IN]OUT parameter (e.g., SET_NAME and SET_ERRHANDLER). Apparently, *implicit* changes to the underlying MPI object (such as MPI_ISEND) do not count / should be IN (i.e., many MPI implementation *do* change the state either on the communicator or something related to the communicator when a send or receive is initiated, even though the communicator is an IN argument). But remember that MPI clearly states that the handle is separate from the underlying MPI object. So why does the binding care if the back- end object is updated? (regardless of whether the change to the object is explicit or implicit) For example, the language-neutral binding for MPI_COMM_SET_NAME has the communicator as an INOUT argument. This clearly falls within the "special case" definition because the function semantics explicitly change state on the underlying MPI object. But note that the C binding is "int MPI_Comm_set_name(MPI_Comm comm, ...)". Notice that the comm is passed by value, not by reference. So even though the language neutral binding called that parameter INOUT, it's not possible for the MPI implementation to change the value of the handle. My claim is that if we want to ensure that the C++ bindings match the C bindings (i.e., that the implementation cannot change the value of the MPI handle), then the method should be const (i.e., cxx_comm.Set_name(...)) *because the handle value will not, and ***cannot***, change*. Simply put: regardless of language or implementation, MPI handles must have true handle semantics. For example: MPI::Intracomm cxx_comm = MPI::COMM_WORLD; cxx_comm.Set_name("C++ r00l3z!"); MPI::COMM_WORLD.Get_name(name, len); cout << name << endl; The above will output "C++ r00l3z!" because cxx_comm and MPI::COMM_WORLD are handles referring to the same underlying communicator. Hence, the only state that the handles have is whatever refers to their back-end MPI object. Having Set_name() be const keeps the *handle* const, not the underlying MPI object. Tying this all together: 1. cxx_comm.Set_name() *cannot* change state on the cxx_comm handle because cxx_comm.Get_name() and MPI::COMM_WORLD.Get_name() must return the same results (the same is true for error handlers). Hence, regardless of the implementation of the C++ bindings, the handle value cannot change. Therefore, this method (and all the others like it) should be const. 2. As a related issue, if no one can remember why the "special case" exists for OUT, then I think we should remove this text and then change all those INOUT parameters for the functions I cited in my earlier proposal to IN. This would make the C++ bindings consistent with the IN/OUT/INOUT specifications of the language-neutral bindings. 3. All the MPI C++ predefined handles should be const for many of the same reasons. Regardless of what happens to the underlying MPI object, the value of the handle cannot ever change. This is guaranteed by MPI-2:2.5.4 pages 10 lines 38-41: "All named constants, with the exceptions noted below for Fortran, can be used in initialization expressions or assignments. These constants do not change values during execution. Opaque objects accessed by constant handles are defined and do not change value between MPI initialization MPI_INIT and MPI completion MPI_FINALIZE." Hence, they should all be "const". ----- In short: C++ gives us stronger protections to ensure that applications don't shoot themselves in the foot. If the MPI predefined handles are const, then statements like "MPI::INT = my_dtype;" will fail to compile. This is a Good Thing. The original C++ bindings tried to take advantage of const, but missed a few points. Ballot two and one of the items in ballot 3 incorrectly tried to fix these points by removing const in several places. That "fixes" the problem, but removes many of the good qualities that we can get in C++ with "const". So let's fix the real problem and leave "const" in the C++ bindings. Are you confused yet? :-) -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 22 Jan '08

22 Jan '08

An alternative-proposal would be to add a clarifying sentence in Terms and Conventions, MPI-2.0 Sect. 2.5.1, page 9, line 7: Handle arguments can be marked at INOUT to indicate that the handle itself may be changed by the routine (e.g., in MPI_TYPE_COMMIT), or to indicate that the object referenced by the handle may be changed but the handle itself is kept unchanged (e.g., MPI_TYPE_SET_NAME). Rolf Rabenseifner On Mon, 21 Jan 2008 09:42:02 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote: >This is not already on Bill's errata page. > >Proposal: change the INOUT designation of the MPI handle parameters in several MPI-2 functions to be IN, because the values of the handles are not changing. Only the underlying MPI objects are changing. The C bindings for each of these functions do *not* pass the MPI handle by reference, therefore disallowing the possibility of these parameters actually being INOUT. By the same argument, the C++ methods for these functions should be const since the C++ object invoking the method will not be changed. > >The functions in question are: > >MPI_*_SET_NAME for communicators, datatypes, windows >MPI_*_SET_ATTR for communicators, datatypes, windows >MPI_*_SET_ERRHANDLER for communicators, files, windows > >Locations of specific text to be changed (INOUT -> IN, add "const" to C ++ methods): > >MPI_COMM_SET_NAME: MPI-2:8.4, p177:35,44 > MPI-2:A.8.5, p336:28 >MPI_TYPE_SET_NAME: MPI-2:8.4, p179:41, p180:2 > MPI-2:A.8.5, p337:2 >MPI_WIN_SET_NAME: MPI-2:8.4, p181:25,35 > MPI-2:A.8.5, p337:36 > >MPI_COMM_SET_ATTR: MPI-2:8.8.1, p201:6,17 > MPI-2:A.8.5, p336:27 >MPI_WIN_SET_ATTR: MPI-2:8.8.2, p204:2,12 > MPI-2:A.8.5, p337:35 >MPI_TYPE_SET_ATTR: MPI-2:8.8.3, p206:26,37 > MPI-2:A.8.5, p337:1 > >MPI_COMM_SET_ERRHANDLER: MPI-2:4.13.1, p62:35,43 > MPI-2:A.8.1, p331:38 >MPI_WIN_SET_ERRHANDLER: MPI-2:4.13.2, p64:2,10 > MPI-2:A.8.1, p333:13 >MPI_FILE_SET_ERRHANDLER: MPI-2:4.13.3, p65:14,22 > MPI-2:A.8.1, p332:34 > >NOTE: The "const" issues of this proposal will be dependent upon a 2nd proposal about re-instituting the "const" on MPI predefined handles that was removed in ballot 2. > >-- >Jeff Squyres >Cisco Systems > 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: MPI::COMM_WORLD and MPI::COMM_SELF should be const
by unknown＠example.com 21 Jan '08

21 Jan '08

On Jan 21, 2008, at 11:48 AM, Rolf Rabenseifner wrote: > As far as I know, this propsal is technical wrong: > MPI-2, Sect.2.5.4, page 10, lines 40-41 clearly allows the changing of > the value of MPI::COMM_WORLD and MPI::COMM_SELF in MPI_Init and > MPI_Finalize. > Therefore, I do not expect, that const is correct. Hmm. If you include the previous two lines (38-41), I read the overall interpretation as the opposite of what you are saying: "All named constants, with the exceptions noted below for Fortran, can be used in initialization expressions or assignments. These constants do not change values during execution. Opaque objects accessed by constant handles are defined and do not change value between MPI initialization MPI_INIT and MPI completion MPI_FINALIZE. To me, that says that the *MPI objects* ("object" in the MPI sense, not the C++ sense) do not change value between INIT and FINALIZE, but the *handles* must be valid for initialization before INIT. I think that the overloading of the word "object" is what is confusing here. Yes, the predefined MPI C++ handles such as MPI::COMM_WORLD are C++ objects (in the C++ sense of the word "object"). But in the MPI sense, MPI::COMM_WORLD and friends are *handles*, representing back- end MPI objets (in the MPI sense of the word "object"). It is critical to keep the difference between the two in mind. The "opaque objects" referred to in MPI-2:2.5.4 are *MPI* objects, not C++ objects. The C++ MPI named constants are just like the C MPI named constants: they must be suitable for initialization [before MPI_INIT] and cannot change value during execution. For example, this code is valid: int main(int argc, char* argv[]) { MPI::Intracomm cxx_comm = MPI::COMM_WORLD; MPI_Comm c_comm = MPI_COMM_WORLD; MPI_Init(NULL, NULL); if (SENDER == MPI::COMM_WORLD.Get_rank()) { // The cxx_comm and c_comm handles are valid even though they were // assigned before MPI_INIT cxx_comm.Send(...); MPI_Send(..., c_comm); else if (RECEIVER == MPI::COMM_WORLD.Get_rank()) { // receive stuff } MPI_Finalize(); return 0; } > Remember that in Ballot 1&2, the MPI Forum already decided > MPI-2 Page 343, line 44 > Remove the const from const MPI::Datatype. > Page 344, lines 13, 23, 32, 38, and 47 > Remove the const from const MPI::Datatype. > Page 345, lines 5 and 11 > Remove the const from const MPI::Datatype. > See http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/errata… Correct. But see my other proposal about restoring those const's (subject: "const" predefined MPI C++ handles"). > And on Jan. 2008 meeting, positve straw vtes wer given for > (in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ballot… > ) > 6. MPI-2, page 345, line 37: Remove the const from const MPI::Op. > MPI-2, page 346, line 20: Remove the const from const MPI::Group. > MPI-2, page 346, add after line 34: > Advice to implementors. If an implementation does not change > the value of > predefined handles while execution of MPI Init, the > implementation is free to > define the predefined operation handles as const MPI::Op and > the predefined > group handle MPI::GROUP EMPTY as const MPI::Group. Other > predefined > handles must not be const because they are allowed as INOUT > argument in > the MPI COMM SET NAME/ATTR and MPI TYPE SET NAME/ATTR routines. Note that this exact item did *not* come up in Bill's slides in the Chicago Jan 08 meeting. It was on the ballot, but this specific item did not get raised during the meeting (so it did not get positive straw votes). Hubert pointed out this item to me on Wednesday and I didn't remember it coming up on Monday or Tuesday. So I asked Bill about it on Wednesday after the meeting; he wasn't sure that he had remembered to put this specific item in the ballot 3 discussion during the meeting. I don't have notes about this item in the discussion, either. I may have missed it...? (but I usually tend to perk up at C++ items) > I'll move this item from Ballot 3 to Ballot 4 because the last > sentence > is not needed when your Proposal "Ballot 4 proposal: INOUT arguments" > will be accepted. All of these ballots are unfortunately intertwined, even though they are technically separate issues -- sorry, everyone! Note that these 3 proposals, taken together, represent a very, very complex set of issues. I have another rollup mail coming on these issues... please stand by. I am struggling to distill a short, concise, easy-to-understand explanation of the issues involved -- I spent a lot of time with Andrew Lumsdaine and Erez today discussing exactly these issues... > > Best regards > Rolf > > On Mon, 21 Jan 2008 10:40:39 -0500 > Jeff Squyres <jsquyres_at_[hidden]> wrote: >> This is not already on Bill's errata page. >> >> Proposal: Make MPI::COMM_WORLD and MPI::COMM_SELF be "const". >> >> Change MPI-2:B.2 p345:18 from >> >> // Type: MPI::Intracomm >> to >> // Type: const MPI::Intracomm >> >> Rationale: The COMM_WORLD and COMM_SELF C++ handles were erroneously >> not marked "const" because of the incorrect INOUT MPI handle >> parameter >> designation of the MPI_COMM_SET_ERRHANDLER, MPI_COMM_SET_ATTR, and >> MPI_COMM_SET_ERRHANDLER functions. This caused the C++ bindings >> methods to not be const, resulting in compile errors if COMM_WORLD >> was >> const and you invoked any of the methods listed above (e.g., >> MPI::COMM_WORLD.Set_errhandler(...)). >> >> The proper solution is to have all the MPI handle arguments be IN >> instead of INOUT (covered in another proposal) and therefore have the >> Set_* functions be const (also covered that other proposal). Once >> that solution is in place, COMM_WORLD and COMM_SELF should be marked >> as "const". Not that many other predefined MPI C++ handles are >> already const; some erroneously had their "const" designation removed >> in ballot 2 -- a different proposal seeks to restore their "const" >> status. >> >> NOTE: This proposal depends on the "change some INOUT parameters to >> IN" proposal. >> >> -- >> 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) > -- Jeff Squyres Cisco Systems

1 0

Ballot 4 - Re: MPI Process Topologies - discussion?
by unknown＠example.com 21 Jan '08

21 Jan '08

This is a proposal for MPI 2.1, Ballot 4. This is a follow up to: Questions about Graph_create, Cart_crate, and Cart_coords in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… Based on the questions for clarification, I propose: Proposal for MPI 2.1, Ballot 4: ------------------------------- MPI-1.1, Sect. 6.5.3, page 181, line 1-3 read: If the size, nnodes, of the graph is smaller than the size of the group of comm, then some processes are returned MPI_COMM_NULL, in analogy to MPI_CART_CREATE and MPI_COMM_SPLIT. but should read If the size, nnodes, of the graph is smaller than the size of the group of comm, then some processes are returned MPI_COMM_NULL, in analogy to MPI_CART_CREATE and MPI_COMM_SPLIT. If the graph is empty, i.e., nnodes == 0, then MPI_COMM_NULL is returned in all processes. ------ Rationale for this clarification: As in MPI_COMM_CREATE, empty groups are allowed, but empty groups are described here in a different way, and should be mentioned explicitly therefore. ------------------------------- After MPI-1.1, Sect. 6.5.3, page 181, line 35, the following paragraph should be added: It is allowed that at a process, a neighbor process is defined multiple in the list of neighbors (i.e., multiple edges). It is also allowed that a process is neighbor to itself (i.e., a self loop in the graph). It is allowed, that the adjacency matrix is not symmetric. Advice to users. Whether using of multiple edges or a non-symmetric adjacency matrix may have possible performance implications is not defined by this standard. The definition of a node-neighbor edge does not imply a direction of the communication. (End of advice to users.) ------ Rationale for this clarification: The Example 6.3, MPI-1.1, page 15, line 29 - page 186, line 13, clearly shows multiple edges between nodes and self loops: the two (multiple) self-loops of node 0 and of node 7. It is nowhere forbidden, that the graph has edges only in one direction. ------------------------------- After MPI-1.1, Sect. 6.4, page 178, end of the sentence on lines 6-7, the following sentence should be added: All input arguments must have identical values on all processes of the group of comm_old. ------ Rationale for this clarification: This statement is missing. ------------------------------- I have split this discussion track into this track on graph topologies and an additional track (will come) on 0-dim MPI_CART_CREATE and MPI_CART_SUB. Discussion should be done through the new mailing list mpi-21_at_cs.uiuc.edu. I have sent out this mail with CC through the old general list mpi-21_at_[hidden] 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

Ballot 4 - Re: MPI-2 thread safety and collectives
by unknown＠example.com 21 Jan '08

21 Jan '08

This is a proposal for MPI 2.1, Ballot 4. This is a follow up to: Thread safety and collective communication in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… After checking the e-mails and looking at - MPI-2 8.7.2 page 195 lines 6-9 Collective calls Matching of collective calls on a communicator, window, or file handle is done according to the order in which the calls are issued at each process. If concurrent threads issue such calls on the same communicator, window or file handle, it is up to the user to make sure the calls are correctly ordered, using interthread synchronization. - MPI-2 6.2.1 Window Creation, page 110, lines 10-12: The call returns an opaque object that represents the group of processes that own and access the set of windows, and the attributes of each window, as specified by the initialization call. - MPI-2 9.2. Opening a File, page 211, line 46 - page 212, line 2: Note that the communicator comm is unaffected by MPI FILE OPEN and continues to be usable in all MPI routines (e.g., MPI SEND). Furthermore, the use of comm will not interfere with I/O behavior. it seems that the standard should be clarified. Proposal for MPI 2.1, Ballot 4: ------------------------------- Add new paragraphs after MPI-2, 8.7.2 page 195 line 9 (the end of the clarification on "Collective calls"): Advice to users. With three concurrent threads in each MPI process of a communicator comm, it is allowed that thread A in each MPI process calls a collective operation on comm, thread B calls a file operation on an existing filehandle that was formerly opened on comm, and thread C invokes one-sided operations on an existing window handle that was also formerly created on comm. (End of advice to users.) Rationale. As already specified in MP_FILE_OPEN and MI_WIN_CREATE, a file handle and a window handle inherit only the group of processes of the underlying communicator, but not the communicator itself. Accesses to communicators, window handles and file handles cannot affect one another. (End of rationale.) Advice to implementors. If the implementation of file or window operations wants to internally use MPI communication then a duplicated communicator handle may be cached on the file or window handle. (End of advice to implementors.) ------------------------------- Reason: The emails have shown, that the current MPI-2 text can be well misunderstood. ------------------------------- Discussion should be done through the new mailing list mpi-21_at_cs.uiuc.edu. I have sent out this mail with CC through the old general list mpi-21_at_[hidden] 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 proposal: MPI::COMM_WORLD and MPI::COMM_SELF should be const
by unknown＠example.com 21 Jan '08

21 Jan '08

As far as I know, this propsal is technical wrong: MPI-2, Sect.2.5.4, page 10, lines 40-41 clearly allows the changing of the value of MPI::COMM_WORLD and MPI::COMM_SELF in MPI_Init and MPI_Finalize. Therefore, I do not expect, that const is correct. Remember that in Ballot 1&2, the MPI Forum already decided MPI-2 Page 343, line 44 Remove the const from const MPI::Datatype. Page 344, lines 13, 23, 32, 38, and 47 Remove the const from const MPI::Datatype. Page 345, lines 5 and 11 Remove the const from const MPI::Datatype. See http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/errata… And on Jan. 2008 meeting, positve straw vtes wer given for (in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ballot… ) 6. MPI-2, page 345, line 37: Remove the const from const MPI::Op. MPI-2, page 346, line 20: Remove the const from const MPI::Group. MPI-2, page 346, add after line 34: Advice to implementors. If an implementation does not change the value of predefined handles while execution of MPI Init, the implementation is free to define the predefined operation handles as const MPI::Op and the predefined group handle MPI::GROUP EMPTY as const MPI::Group. Other predefined handles must not be const because they are allowed as INOUT argument in the MPI COMM SET NAME/ATTR and MPI TYPE SET NAME/ATTR routines. I'll move this item from Ballot 3 to Ballot 4 because the last sentence is not needed when your Proposal "Ballot 4 proposal: INOUT arguments" will be accepted. Best regards Rolf On Mon, 21 Jan 2008 10:40:39 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote: >This is not already on Bill's errata page. > >Proposal: Make MPI::COMM_WORLD and MPI::COMM_SELF be "const". > >Change MPI-2:B.2 p345:18 from > > // Type: MPI::Intracomm >to > // Type: const MPI::Intracomm > >Rationale: The COMM_WORLD and COMM_SELF C++ handles were erroneously >not marked "const" because of the incorrect INOUT MPI handle parameter >designation of the MPI_COMM_SET_ERRHANDLER, MPI_COMM_SET_ATTR, and >MPI_COMM_SET_ERRHANDLER functions. This caused the C++ bindings >methods to not be const, resulting in compile errors if COMM_WORLD was >const and you invoked any of the methods listed above (e.g., >MPI::COMM_WORLD.Set_errhandler(...)). > >The proper solution is to have all the MPI handle arguments be IN >instead of INOUT (covered in another proposal) and therefore have the >Set_* functions be const (also covered that other proposal). Once >that solution is in place, COMM_WORLD and COMM_SELF should be marked >as "const". Not that many other predefined MPI C++ handles are >already const; some erroneously had their "const" designation removed >in ballot 2 -- a different proposal seeks to restore their "const" >status. > >NOTE: This proposal depends on the "change some INOUT parameters to >IN" proposal. > >-- >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