2004-07-14 18:11:03 +04:00
|
|
|
// -*- c++ -*-
|
|
|
|
|
//
|
2005-11-05 22:57:48 +03:00
|
|
|
// 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.
|
2004-11-28 23:09:25 +03:00
|
|
|
// Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
|
|
|
// University of Stuttgart. All rights reserved.
|
2005-03-24 15:43:37 +03:00
|
|
|
// 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.
|
2007-01-10 02:48:39 +03:00
|
|
|
// Copyright (c) 2007 Sun Microsystems, Inc. All rights reserved.
|
2004-11-22 04:38:40 +03:00
|
|
|
// $COPYRIGHT$
|
|
|
|
|
//
|
|
|
|
|
// Additional copyrights may follow
|
|
|
|
|
//
|
2004-07-14 18:11:03 +04:00
|
|
|
// $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) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
|
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) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
2007-01-10 19:41:21 +03:00
|
|
|
// 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)
|
2007-01-10 02:48:39 +03:00
|
|
|
bool Get_attr(int win_keyval, void* attribute_val) const;
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
|
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);
|
2006-12-31 02:41:42 +03:00
|
|
|
|
|
|
|
|
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;
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
|
PMPI::Win pmpi_win;
|
|
|
|
|
#else
|
|
|
|
|
MPI_Win mpi_win;
|
|
|
|
|
#endif
|
|
|
|
|
};
|