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/ballot3... ) 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