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

213 строки
6.6 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.
// Copyright (c) 2006-2009 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() : mpi_win(MPI_WIN_NULL) { }
// 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_function(Win &, int *, ... );
typedef Errhandler_function Errhandler_fn
__mpi_interface_deprecated__("MPI::Win::Errhandler_fn was deprecated in MPI-2.2; use MPI::Win::Errhandler_function instead");
//
// Errhandler
//
static MPI::Errhandler Create_errhandler(Errhandler_function* function);
virtual void Set_errhandler(const MPI::Errhandler& errhandler) const;
virtual MPI::Errhandler Get_errhandler() const;
//
// 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;
Fixes trac:817 The C++ bindings were not tracking keyvals properly -- they were freeing some internal meta data when Free_keyval() was called, not when the keyval was actually destroyed (keyvals are refcounted in the C layer, just like all other MPI objects, because they can live for long after their corresponding Free call is invoked). This commit fixes this problem and several other things: * Add infrastructure on the ompi_attribute_keyval_t for an "extra" destructor pointer that will be invoked during the "real" constructor (i.e., when OBJ_RELEASE puts the refcount to 0). This allows calling back into the C++ layer to release meta data associated with the keyval. * Adjust all cases where keyvals are created to pass in relevant destructors (NULL or the C++ destructor). * Do essentially the same for MPI::Comm, MPI::Win, and MPI:Datatype: * Move several functions out of the .cc file into the _inln.h file since they no longer require locks * Make the 4 Create_keyval() functions call a common back-end keyval creation function that does the Right Thing depending on whether C or C++ function pointers were used for the keyval functions. The back-end function does not call the corresponding C MPI_*_create_keyval function, but rather does the work itself so that it can associate a "destructor" callback for the C++ bindings for when the keyval is actually destroyed. * Change a few type names to be more indicative of what they are (mostly dealing with keyvals [not "keys"]). * Add the 3 missing bindings for MPI::Comm::Create_keyval(). * Remove MPI::Comm::comm_map (and associated types) because it's no longer necessary in the intercepts -- it was a by-product of being a portable C++ bindings layer. Now we can just query the C layer directly to figure out what type a communicator is. This solves some logistics / callback issues, too. * Rename several types, variables, and fix many comments in the back-end C attribute implementation to make the names really reflect what they are (keyvals vs. attributes). The previous names heavily overloaded the name "key" and were ''extremely'' confusing. This commit was SVN r13565. The following Trac tickets were found above: Ticket 817 --> https://svn.open-mpi.org/trac/ompi/ticket/817
2007-02-09 02:50:04 +03:00
// Need 4 overloaded versions of this function because per the
// MPI-2 spec, you can mix-n-match the C predefined functions with
// C++ functions.
static int Create_keyval(Copy_attr_function* win_copy_attr_fn,
Delete_attr_function* win_delete_attr_fn,
void* extra_state);
static int Create_keyval(MPI_Win_copy_attr_function* win_copy_attr_fn,
MPI_Win_delete_attr_function* win_delete_attr_fn,
void* extra_state);
static int Create_keyval(Copy_attr_function* win_copy_attr_fn,
MPI_Win_delete_attr_function* win_delete_attr_fn,
void* extra_state);
static int Create_keyval(MPI_Win_copy_attr_function* win_copy_attr_fn,
Delete_attr_function* win_delete_attr_fn,
void* extra_state);
Fixes trac:817 The C++ bindings were not tracking keyvals properly -- they were freeing some internal meta data when Free_keyval() was called, not when the keyval was actually destroyed (keyvals are refcounted in the C layer, just like all other MPI objects, because they can live for long after their corresponding Free call is invoked). This commit fixes this problem and several other things: * Add infrastructure on the ompi_attribute_keyval_t for an "extra" destructor pointer that will be invoked during the "real" constructor (i.e., when OBJ_RELEASE puts the refcount to 0). This allows calling back into the C++ layer to release meta data associated with the keyval. * Adjust all cases where keyvals are created to pass in relevant destructors (NULL or the C++ destructor). * Do essentially the same for MPI::Comm, MPI::Win, and MPI:Datatype: * Move several functions out of the .cc file into the _inln.h file since they no longer require locks * Make the 4 Create_keyval() functions call a common back-end keyval creation function that does the Right Thing depending on whether C or C++ function pointers were used for the keyval functions. The back-end function does not call the corresponding C MPI_*_create_keyval function, but rather does the work itself so that it can associate a "destructor" callback for the C++ bindings for when the keyval is actually destroyed. * Change a few type names to be more indicative of what they are (mostly dealing with keyvals [not "keys"]). * Add the 3 missing bindings for MPI::Comm::Create_keyval(). * Remove MPI::Comm::comm_map (and associated types) because it's no longer necessary in the intercepts -- it was a by-product of being a portable C++ bindings layer. Now we can just query the C layer directly to figure out what type a communicator is. This solves some logistics / callback issues, too. * Rename several types, variables, and fix many comments in the back-end C attribute implementation to make the names really reflect what they are (keyvals vs. attributes). The previous names heavily overloaded the name "key" and were ''extremely'' confusing. This commit was SVN r13565. The following Trac tickets were found above: Ticket 817 --> https://svn.open-mpi.org/trac/ompi/ticket/817
2007-02-09 02:50:04 +03:00
protected:
// Back-end function to do the heavy lifting for creating the
// keyval
Fixes trac:817 The C++ bindings were not tracking keyvals properly -- they were freeing some internal meta data when Free_keyval() was called, not when the keyval was actually destroyed (keyvals are refcounted in the C layer, just like all other MPI objects, because they can live for long after their corresponding Free call is invoked). This commit fixes this problem and several other things: * Add infrastructure on the ompi_attribute_keyval_t for an "extra" destructor pointer that will be invoked during the "real" constructor (i.e., when OBJ_RELEASE puts the refcount to 0). This allows calling back into the C++ layer to release meta data associated with the keyval. * Adjust all cases where keyvals are created to pass in relevant destructors (NULL or the C++ destructor). * Do essentially the same for MPI::Comm, MPI::Win, and MPI:Datatype: * Move several functions out of the .cc file into the _inln.h file since they no longer require locks * Make the 4 Create_keyval() functions call a common back-end keyval creation function that does the Right Thing depending on whether C or C++ function pointers were used for the keyval functions. The back-end function does not call the corresponding C MPI_*_create_keyval function, but rather does the work itself so that it can associate a "destructor" callback for the C++ bindings for when the keyval is actually destroyed. * Change a few type names to be more indicative of what they are (mostly dealing with keyvals [not "keys"]). * Add the 3 missing bindings for MPI::Comm::Create_keyval(). * Remove MPI::Comm::comm_map (and associated types) because it's no longer necessary in the intercepts -- it was a by-product of being a portable C++ bindings layer. Now we can just query the C layer directly to figure out what type a communicator is. This solves some logistics / callback issues, too. * Rename several types, variables, and fix many comments in the back-end C attribute implementation to make the names really reflect what they are (keyvals vs. attributes). The previous names heavily overloaded the name "key" and were ''extremely'' confusing. This commit was SVN r13565. The following Trac tickets were found above: Ticket 817 --> https://svn.open-mpi.org/trac/ompi/ticket/817
2007-02-09 02:50:04 +03:00
static int do_create_keyval(MPI_Win_copy_attr_function* c_copy_fn,
MPI_Win_delete_attr_function* c_delete_fn,
Copy_attr_function* cxx_copy_fn,
Delete_attr_function* cxx_delete_fn,
void* extra_state, int &keyval);
Fixes trac:817 The C++ bindings were not tracking keyvals properly -- they were freeing some internal meta data when Free_keyval() was called, not when the keyval was actually destroyed (keyvals are refcounted in the C layer, just like all other MPI objects, because they can live for long after their corresponding Free call is invoked). This commit fixes this problem and several other things: * Add infrastructure on the ompi_attribute_keyval_t for an "extra" destructor pointer that will be invoked during the "real" constructor (i.e., when OBJ_RELEASE puts the refcount to 0). This allows calling back into the C++ layer to release meta data associated with the keyval. * Adjust all cases where keyvals are created to pass in relevant destructors (NULL or the C++ destructor). * Do essentially the same for MPI::Comm, MPI::Win, and MPI:Datatype: * Move several functions out of the .cc file into the _inln.h file since they no longer require locks * Make the 4 Create_keyval() functions call a common back-end keyval creation function that does the Right Thing depending on whether C or C++ function pointers were used for the keyval functions. The back-end function does not call the corresponding C MPI_*_create_keyval function, but rather does the work itself so that it can associate a "destructor" callback for the C++ bindings for when the keyval is actually destroyed. * Change a few type names to be more indicative of what they are (mostly dealing with keyvals [not "keys"]). * Add the 3 missing bindings for MPI::Comm::Create_keyval(). * Remove MPI::Comm::comm_map (and associated types) because it's no longer necessary in the intercepts -- it was a by-product of being a portable C++ bindings layer. Now we can just query the C layer directly to figure out what type a communicator is. This solves some logistics / callback issues, too. * Rename several types, variables, and fix many comments in the back-end C attribute implementation to make the names really reflect what they are (keyvals vs. attributes). The previous names heavily overloaded the name "key" and were ''extremely'' confusing. This commit was SVN r13565. The following Trac tickets were found above: Ticket 817 --> https://svn.open-mpi.org/trac/ompi/ticket/817
2007-02-09 02:50:04 +03:00
public:
virtual void Delete_attr(int win_keyval);
static void Free_keyval(int& win_keyval);
// version 1: pre-errata Get_attr (not correct, but probably nice to support
bool Get_attr(const Win& win, int win_keyval,
void* attribute_val) const;
// version 2: post-errata Get_attr (correct, but no one seems to know about it)
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);
// Data that is passed through keyval create when C++ callback
// functions are used
struct keyval_intercept_data_t {
MPI_Win_copy_attr_function *c_copy_fn;
MPI_Win_delete_attr_function *c_delete_fn;
Copy_attr_function* cxx_copy_fn;
Delete_attr_function* cxx_delete_fn;
void *extra_state;
};
// Protect the global list from multiple thread access
static opal_mutex_t cxx_extra_states_lock;
protected:
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
PMPI::Win pmpi_win;
#else
MPI_Win mpi_win;
#endif
};