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

178 строки
5.0 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 (c) 2007 Sun Microsystems, Inc. All rights reserved.
// $COPYRIGHT$
//
// Additional copyrights may follow
//
// $HEADER$
//
class Win {
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
// friend class P;
#endif
friend class MPI::Comm; //so I can access pmpi_win data member in comm.cc
friend class MPI::Request; //and also from request.cc
public:
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
// construction / destruction
Win() { }
virtual ~Win() { }
// copy / assignment
Win(const Win& data) : pmpi_win(data.pmpi_win) { }
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
Win(MPI_Win i) : pmpi_win(i) { }
Win& operator=(const Win& data) {
pmpi_win = data.pmpi_win; return *this; }
// comparison, don't need for win
// inter-language operability
Win& operator= (const MPI_Win &i) {
pmpi_win = i; return *this; }
operator MPI_Win () const { return pmpi_win; }
// operator MPI_Win* () const { return pmpi_win; }
operator const PMPI::Win&() const { return pmpi_win; }
#else
Win() { }
// copy
Win(const Win& data) : mpi_win(data.mpi_win) { }
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
Win(MPI_Win i) : mpi_win(i) { }
virtual ~Win() { }
Win& operator=(const Win& data) {
mpi_win = data.mpi_win; return *this; }
// comparison, don't need for win
// inter-language operability
Win& operator= (const MPI_Win &i) {
mpi_win = i; return *this; }
operator MPI_Win () const { return mpi_win; }
// operator MPI_Win* () const { return (MPI_Win*)&mpi_win; }
#endif
//
// User defined functions
//
typedef int Copy_attr_function(const Win& oldwin, int win_keyval,
void* extra_state, void* attribute_val_in,
void* attribute_val_out, bool& flag);
typedef int Delete_attr_function(Win& win, int win_keyval,
void* attribute_val, void* extra_state);
typedef void Errhandler_fn(Win &, int *, ... );
//
// Miscellany
//
static MPI::Errhandler Create_errhandler(Errhandler_fn* function);
virtual MPI::Errhandler Get_errhandler() const;
virtual void Set_errhandler(const MPI::Errhandler& errhandler);
//
// One sided communication
//
virtual void Accumulate(const void* origin_addr, int origin_count,
const MPI::Datatype& origin_datatype,
int target_rank, MPI::Aint target_disp,
int target_count,
const MPI::Datatype& target_datatype,
const MPI::Op& op) const;
virtual void Complete() const;
static Win Create(const void* base, MPI::Aint size, int disp_unit,
const MPI::Info& info, const MPI::Intracomm& comm);
virtual void Fence(int assert) const;
virtual void Free();
virtual void Get(const void *origin_addr, int origin_count,
const MPI::Datatype& origin_datatype, int target_rank,
MPI::Aint target_disp, int target_count,
const MPI::Datatype& target_datatype) const;
virtual MPI::Group Get_group() const;
virtual void Lock(int lock_type, int rank, int assert) const;
virtual void Post(const MPI::Group& group, int assert) const;
virtual void Put(const void* origin_addr, int origin_count,
const MPI::Datatype& origin_datatype, int target_rank,
MPI::Aint target_disp, int target_count,
const MPI::Datatype& target_datatype) const;
virtual void Start(const MPI::Group& group, int assert) const;
virtual bool Test() const;
virtual void Unlock(int rank) const;
virtual void Wait() const;
//
// External Interfaces
//
virtual void Call_errhandler(int errorcode) const;
static int Create_keyval(Copy_attr_function* win_copy_attr_fn,
Delete_attr_function* win_delete_attr_fn,
void* extra_state);
virtual void Delete_attr(int win_keyval);
static void Free_keyval(int& win_keyval);
bool Get_attr(int win_keyval, void* attribute_val) const;
virtual void Get_name(char* win_name, int& resultlen) const;
virtual void Set_attr(int win_keyval, const void* attribute_val);
virtual void Set_name(const char* win_name);
Errhandler* my_errhandler;
typedef ::std::map<MPI_Win, Win*> mpi_win_map_t;
static mpi_win_map_t mpi_win_map;
typedef ::std::pair<Win::Copy_attr_function*, Win::Delete_attr_function*> key_pair_t;
typedef ::std::map<int, key_pair_t*> mpi_win_key_fn_map_t;
static mpi_win_key_fn_map_t mpi_win_key_fn_map;
protected:
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
PMPI::Win pmpi_win;
#else
MPI_Win mpi_win;
#endif
};