[mpi-21] Ballot 4 proposal: MPI::COMM_WORLD and MPI::COMM_SELF should be const
Jeff Squyres
jsquyres at [hidden]
Mon Jan 21 19:50:38 CST 2008
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-20-adopted.pdf
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.pdf
> )
> 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
More information about the Mpi-21
mailing list