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.
|
2004-11-22 04:38:40 +03:00
|
|
|
// $COPYRIGHT$
|
|
|
|
//
|
|
|
|
// Additional copyrights may follow
|
|
|
|
//
|
2004-07-14 18:11:03 +04:00
|
|
|
// $HEADER$
|
|
|
|
//
|
|
|
|
|
|
|
|
|
|
|
|
class Request {
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
// friend class PMPI::Request;
|
|
|
|
#endif
|
|
|
|
public:
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
|
|
|
|
// construction
|
|
|
|
Request() { }
|
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
|
|
|
Request(MPI_Request i) : pmpi_request(i) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
// copy / assignment
|
|
|
|
Request(const Request& r) : pmpi_request(r.pmpi_request) { }
|
|
|
|
|
|
|
|
Request(const PMPI::Request& r) : pmpi_request(r) { }
|
|
|
|
|
|
|
|
virtual ~Request() {}
|
|
|
|
|
|
|
|
Request& operator=(const Request& r) {
|
|
|
|
pmpi_request = r.pmpi_request; return *this; }
|
|
|
|
|
|
|
|
// comparison
|
|
|
|
bool operator== (const Request &a)
|
|
|
|
{ return (bool)(pmpi_request == a.pmpi_request); }
|
|
|
|
bool operator!= (const Request &a)
|
|
|
|
{ return (bool)!(*this == a); }
|
|
|
|
|
|
|
|
// inter-language operability
|
|
|
|
Request& operator= (const MPI_Request &i) {
|
|
|
|
pmpi_request = i; return *this; }
|
|
|
|
|
|
|
|
operator MPI_Request () const { return pmpi_request; }
|
|
|
|
// operator MPI_Request* () const { return pmpi_request; }
|
|
|
|
operator const PMPI::Request&() const { return pmpi_request; }
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
// construction / destruction
|
|
|
|
Request() { mpi_request = MPI_REQUEST_NULL; }
|
|
|
|
virtual ~Request() {}
|
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
|
|
|
Request(MPI_Request i) : mpi_request(i) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
// copy / assignment
|
|
|
|
Request(const Request& r) : mpi_request(r.mpi_request) { }
|
|
|
|
|
|
|
|
Request& operator=(const Request& r) {
|
|
|
|
mpi_request = r.mpi_request; return *this; }
|
|
|
|
|
|
|
|
// comparison
|
|
|
|
bool operator== (const Request &a)
|
|
|
|
{ return (bool)(mpi_request == a.mpi_request); }
|
|
|
|
bool operator!= (const Request &a)
|
|
|
|
{ return (bool)!(*this == a); }
|
|
|
|
|
|
|
|
// inter-language operability
|
|
|
|
Request& operator= (const MPI_Request &i) {
|
|
|
|
mpi_request = i; return *this; }
|
|
|
|
operator MPI_Request () const { return mpi_request; }
|
|
|
|
// operator MPI_Request* () const { return (MPI_Request*)&mpi_request; }
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
//
|
|
|
|
// Point-to-Point Communication
|
|
|
|
//
|
|
|
|
|
|
|
|
virtual void Wait(Status &status);
|
|
|
|
|
|
|
|
virtual void Wait();
|
|
|
|
|
|
|
|
virtual bool Test(Status &status);
|
|
|
|
|
|
|
|
virtual bool Test();
|
|
|
|
|
|
|
|
virtual void Free(void);
|
|
|
|
|
|
|
|
static int Waitany(int count, Request array[], Status& status);
|
|
|
|
|
|
|
|
static int Waitany(int count, Request array[]);
|
|
|
|
|
|
|
|
static bool Testany(int count, Request array[], int& index, Status& status);
|
|
|
|
|
|
|
|
static bool Testany(int count, Request array[], int& index);
|
|
|
|
|
|
|
|
static void Waitall(int count, Request req_array[], Status stat_array[]);
|
|
|
|
|
|
|
|
static void Waitall(int count, Request req_array[]);
|
|
|
|
|
|
|
|
static bool Testall(int count, Request req_array[], Status stat_array[]);
|
|
|
|
|
|
|
|
static bool Testall(int count, Request req_array[]);
|
|
|
|
|
|
|
|
static int Waitsome(int incount, Request req_array[],
|
|
|
|
int array_of_indices[], Status stat_array[]) ;
|
|
|
|
|
|
|
|
static int Waitsome(int incount, Request req_array[],
|
|
|
|
int array_of_indices[]);
|
|
|
|
|
|
|
|
static int Testsome(int incount, Request req_array[],
|
|
|
|
int array_of_indices[], Status stat_array[]);
|
|
|
|
|
|
|
|
static int Testsome(int incount, Request req_array[],
|
|
|
|
int array_of_indices[]);
|
|
|
|
|
|
|
|
virtual void Cancel(void) const;
|
|
|
|
|
2006-01-09 21:10:12 +03:00
|
|
|
virtual bool Get_status(Status& status) const;
|
|
|
|
|
|
|
|
virtual bool Get_status() const;
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
protected:
|
|
|
|
#if ! 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
MPI_Request mpi_request;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
PMPI::Request pmpi_request;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
class Prequest : public Request {
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
// friend class PMPI::Prequest;
|
|
|
|
#endif
|
|
|
|
public:
|
|
|
|
|
|
|
|
Prequest() { }
|
|
|
|
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
Prequest(const Request& p) : Request(p), pmpi_request(p) { }
|
|
|
|
|
|
|
|
Prequest(const PMPI::Prequest& r) :
|
|
|
|
Request((const PMPI::Request&)r),
|
|
|
|
pmpi_request(r) { }
|
|
|
|
|
|
|
|
Prequest(const MPI_Request &i) : Request(i), pmpi_request(i) { }
|
|
|
|
|
|
|
|
virtual ~Prequest() { }
|
|
|
|
|
|
|
|
Prequest& operator=(const Request& r) {
|
|
|
|
Request::operator=(r);
|
|
|
|
pmpi_request = (PMPI::Prequest)r; return *this; }
|
|
|
|
|
|
|
|
Prequest& operator=(const Prequest& r) {
|
|
|
|
Request::operator=(r);
|
|
|
|
pmpi_request = r.pmpi_request; return *this; }
|
|
|
|
#else
|
|
|
|
Prequest(const Request& p) : Request(p) { }
|
|
|
|
|
|
|
|
Prequest(const MPI_Request &i) : Request(i) { }
|
|
|
|
|
|
|
|
virtual ~Prequest() { }
|
|
|
|
|
|
|
|
Prequest& operator=(const Request& r) {
|
|
|
|
mpi_request = r; return *this; }
|
|
|
|
|
|
|
|
Prequest& operator=(const Prequest& r) {
|
|
|
|
mpi_request = r.mpi_request; return *this; }
|
|
|
|
#endif
|
|
|
|
|
|
|
|
virtual void Start();
|
|
|
|
|
|
|
|
static void Startall(int count, Prequest array_of_requests[]);
|
|
|
|
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
private:
|
|
|
|
PMPI::Prequest pmpi_request;
|
|
|
|
#endif
|
|
|
|
};
|
2006-10-24 00:17:30 +04:00
|
|
|
|
2006-11-06 21:42:00 +03:00
|
|
|
|
|
|
|
//
|
|
|
|
// Generalized requests
|
|
|
|
//
|
2006-10-24 00:17:30 +04:00
|
|
|
class Grequest : public MPI::Request {
|
|
|
|
public:
|
|
|
|
typedef int Query_function(void *, Status&);
|
|
|
|
typedef int Free_function(void *);
|
|
|
|
typedef int Cancel_function(void *, bool);
|
|
|
|
|
|
|
|
Grequest() {}
|
|
|
|
Grequest(const Request& req) : Request(req) {}
|
|
|
|
Grequest(const MPI_Request &req) : Request(req) {}
|
|
|
|
virtual ~Grequest() {}
|
|
|
|
|
|
|
|
Grequest& operator=(const Request& req) {
|
|
|
|
mpi_request = req; return(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
Grequest& operator=(const Grequest& req) {
|
|
|
|
mpi_request = req.mpi_request; return(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
static Grequest Start(Query_function *, Free_function *,
|
|
|
|
Cancel_function *, void *);
|
|
|
|
|
|
|
|
virtual void Complete();
|
|
|
|
};
|
2006-11-06 21:42:00 +03:00
|
|
|
|
|
|
|
//
|
|
|
|
// Type used for intercepting Generalized requests in the C++ layer so
|
|
|
|
// that the type can be converted to C++ types before invoking the
|
|
|
|
// user-specified C++ callbacks.
|
|
|
|
//
|
|
|
|
struct Grequest_intercept_t {
|
|
|
|
void *git_extra;
|
|
|
|
Grequest::Query_function *git_cxx_query_fn;
|
|
|
|
Grequest::Free_function *git_cxx_free_fn;
|
|
|
|
Grequest::Cancel_function *git_cxx_cancel_fn;
|
|
|
|
};
|