1
1
openmpi/ompi/mpi/cxx/intracomm.h

167 строки
5.1 KiB
C
Исходник Обычный вид История

// -*- c++ -*-
//
// Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
// University Research and Technology
// Corporation. All rights reserved.
// Copyright (c) 2004-2005 The University of Tennessee and The University
// of Tennessee Research Foundation. All rights
// reserved.
// Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
// University of Stuttgart. All rights reserved.
// Copyright (c) 2004-2005 The Regents of the University of California.
// All rights reserved.
This is a workaround to bug in the Intel C++ compiler, version 9.1 (all versions up to and including 20060925). The issue has been reported to Intel, along with a small [non-MPI] test program that reproduces the problem (the test program and the OMPI C++ bindings work fine with Intel C++ 9.0 and many other C++ compilers). In short, a static initializer for a global variable (i.e., its constructor is fired before main()) that takes as an argument a reference to a typedef'd type will simply get the wrong value in the argument. Specifically: {{{ namespace MPI { Intracomm COMM_WORLD(MPI_COMM_WORLD); } }}} The constructor for MPI::Intracomm should get the value of &ompi_mpi_comm_world. It does not; it seems to get a random value. As mandated by MPI-2, annex B.13.4, for C/C++ interoperability, the prototype for this constructor is: {{{ class Intracomm { public: Intracomm(const MPI_Comm& data); }; }}} Experiments with icpc 9.1/20060925 have shown that removing the reference from the prototype makes it work (!). After lots of discussions about this issue with a C++ expert (Doug Gregor from IU), we decided the following (cut-n-paste from an e-mail): ----- > So here's my question: given that OMPI's MPI_<CLASS> types are all > pointers, is there any legal MPI program that adheres to the above > bindings that would fail to compile or work properly if we simply > removed the "&" from the second binding, above? I don't know of any way that a program could detect this change. FWIW, the C++ committee has agreed that implementation of the C++ standard library are allowed to decide arbitrarily between const& and by-value. If they don't care, MPI users won't care. When you remove the '&', I suggest also removing the "const". It is redundant, but can trigger some strange name mangling in Sun's C++ compiler. ----- So with this change: * we now work again with the Intel 9.1 compiler * our C++ bindings do not exactly conform to the MPI-2 spec, but valid/legal MPI C++ apps cannot tell the difference (i.e., the functionality is the same) This commit was SVN r12514.
2006-11-09 20:34:12 +03:00
// Copyright (c) 2006 Cisco Systems, Inc. All rights reserved.
// $COPYRIGHT$
//
// Additional copyrights may follow
//
// $HEADER$
//
class Intracomm : public Comm {
public:
// construction
Intracomm() { }
// copy
Intracomm(const Comm_Null& data) : Comm(data) { }
// inter-language operability
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
//NOTE: it is extremely important that Comm(data) happens below
// because there is a not only pmpi_comm in this Intracomm but
// there is also a pmpi_comm in the inherited Comm part. Both
// of these pmpi_comm's need to be initialized with the same
// MPI_Comm object. Also the assignment operators must take this
// into account.
Intracomm(const Intracomm& data) : Comm(data), pmpi_comm(data) { }
This is a workaround to bug in the Intel C++ compiler, version 9.1 (all versions up to and including 20060925). The issue has been reported to Intel, along with a small [non-MPI] test program that reproduces the problem (the test program and the OMPI C++ bindings work fine with Intel C++ 9.0 and many other C++ compilers). In short, a static initializer for a global variable (i.e., its constructor is fired before main()) that takes as an argument a reference to a typedef'd type will simply get the wrong value in the argument. Specifically: {{{ namespace MPI { Intracomm COMM_WORLD(MPI_COMM_WORLD); } }}} The constructor for MPI::Intracomm should get the value of &ompi_mpi_comm_world. It does not; it seems to get a random value. As mandated by MPI-2, annex B.13.4, for C/C++ interoperability, the prototype for this constructor is: {{{ class Intracomm { public: Intracomm(const MPI_Comm& data); }; }}} Experiments with icpc 9.1/20060925 have shown that removing the reference from the prototype makes it work (!). After lots of discussions about this issue with a C++ expert (Doug Gregor from IU), we decided the following (cut-n-paste from an e-mail): ----- > So here's my question: given that OMPI's MPI_<CLASS> types are all > pointers, is there any legal MPI program that adheres to the above > bindings that would fail to compile or work properly if we simply > removed the "&" from the second binding, above? I don't know of any way that a program could detect this change. FWIW, the C++ committee has agreed that implementation of the C++ standard library are allowed to decide arbitrarily between const& and by-value. If they don't care, MPI users won't care. When you remove the '&', I suggest also removing the "const". It is redundant, but can trigger some strange name mangling in Sun's C++ compiler. ----- So with this change: * we now work again with the Intel 9.1 compiler * our C++ bindings do not exactly conform to the MPI-2 spec, but valid/legal MPI C++ apps cannot tell the difference (i.e., the functionality is the same) This commit was SVN r12514.
2006-11-09 20:34:12 +03:00
Intracomm(MPI_Comm data) : Comm(data), pmpi_comm(data) { }
Intracomm(const PMPI::Intracomm& data)
: Comm((const PMPI::Comm&)data), pmpi_comm(data) { }
// assignment
Intracomm& operator=(const Intracomm& data) {
Comm::operator=(data);
pmpi_comm = data.pmpi_comm;
return *this;
}
Intracomm& operator=(const Comm_Null& data) {
Comm::operator=(data);
pmpi_comm = (PMPI::Intracomm)data; return *this;
}
// inter-language operability
Intracomm& operator=(const MPI_Comm& data) {
Comm::operator=(data);
pmpi_comm = data;
return *this;
}
#else
Intracomm(const Intracomm& data) : Comm(data.mpi_comm) { }
This is a workaround to bug in the Intel C++ compiler, version 9.1 (all versions up to and including 20060925). The issue has been reported to Intel, along with a small [non-MPI] test program that reproduces the problem (the test program and the OMPI C++ bindings work fine with Intel C++ 9.0 and many other C++ compilers). In short, a static initializer for a global variable (i.e., its constructor is fired before main()) that takes as an argument a reference to a typedef'd type will simply get the wrong value in the argument. Specifically: {{{ namespace MPI { Intracomm COMM_WORLD(MPI_COMM_WORLD); } }}} The constructor for MPI::Intracomm should get the value of &ompi_mpi_comm_world. It does not; it seems to get a random value. As mandated by MPI-2, annex B.13.4, for C/C++ interoperability, the prototype for this constructor is: {{{ class Intracomm { public: Intracomm(const MPI_Comm& data); }; }}} Experiments with icpc 9.1/20060925 have shown that removing the reference from the prototype makes it work (!). After lots of discussions about this issue with a C++ expert (Doug Gregor from IU), we decided the following (cut-n-paste from an e-mail): ----- > So here's my question: given that OMPI's MPI_<CLASS> types are all > pointers, is there any legal MPI program that adheres to the above > bindings that would fail to compile or work properly if we simply > removed the "&" from the second binding, above? I don't know of any way that a program could detect this change. FWIW, the C++ committee has agreed that implementation of the C++ standard library are allowed to decide arbitrarily between const& and by-value. If they don't care, MPI users won't care. When you remove the '&', I suggest also removing the "const". It is redundant, but can trigger some strange name mangling in Sun's C++ compiler. ----- So with this change: * we now work again with the Intel 9.1 compiler * our C++ bindings do not exactly conform to the MPI-2 spec, but valid/legal MPI C++ apps cannot tell the difference (i.e., the functionality is the same) This commit was SVN r12514.
2006-11-09 20:34:12 +03:00
inline Intracomm(MPI_Comm data);
// assignment
Intracomm& operator=(const Intracomm& data) {
mpi_comm = data.mpi_comm; return *this;
}
Intracomm& operator=(const Comm_Null& data) {
mpi_comm = data; return *this;
}
// inter-language operability
Intracomm& operator=(const MPI_Comm& data) {
mpi_comm = data; return *this; }
#endif
//
// Collective Communication
//
// All the rest are up in comm.h -- Scan and Exscan are not defined
// in intercomm's, so they're down here in Intracomm.
//
virtual void
Scan(const void *sendbuf, void *recvbuf, int count,
const Datatype & datatype, const Op & op) const;
virtual void
Exscan(const void *sendbuf, void *recvbuf, int count,
const Datatype & datatype, const Op & op) const;
//
// Communicator maintenance
//
Intracomm Dup() const;
virtual Intracomm& Clone() const;
virtual Intracomm
Create(const Group& group) const;
virtual Intracomm
Split(int color, int key) const;
virtual Intercomm
Create_intercomm(int local_leader, const Comm& peer_comm,
int remote_leader, int tag) const;
virtual Cartcomm
Create_cart(int ndims, const int dims[],
const bool periods[], bool reorder) const;
virtual Graphcomm
Create_graph(int nnodes, const int index[],
const int edges[], bool reorder) const;
//
// Process Creation and Management
//
virtual Intercomm Accept(const char* port_name, const Info& info, int root)
const;
virtual Intercomm Connect(const char* port_name, const Info& info, int root)
const;
virtual Intercomm Spawn(const char* command, const char* argv[],
int maxprocs, const Info& info, int root) const;
virtual Intercomm Spawn(const char* command, const char* argv[],
int maxprocs, const Info& info,
int root, int array_of_errcodes[]) const;
virtual Intercomm Spawn_multiple(int count, const char* array_of_commands[],
const char** array_of_argv[],
const int array_of_maxprocs[],
const Info array_of_info[], int root);
virtual Intercomm Spawn_multiple(int count, const char* array_of_commands[],
const char** array_of_argv[],
const int array_of_maxprocs[],
const Info array_of_info[], int root,
int array_of_errcodes[]);
//#if 0 /* OMPI_ENABLE_MPI_PROFILING */
// virtual const PMPI::Comm& get_pmpi_comm() const { return pmpi_comm; }
//#endif
protected:
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
PMPI::Intracomm pmpi_comm;
#endif
// Convert an array of p_nbr Info object into an array of MPI_Info.
// A pointer to the allocated array is returned and must be
// eventually deleted.
static inline MPI_Info *convert_info_to_mpi_info(int p_nbr,
const Info p_info_tbl[]);
};