1
1
Граф коммитов

10 Коммитов

Автор SHA1 Сообщение Дата
Jeff Squyres
72bef32e65 Convert the C++ Comm keyval creation and intercept callbacks to *not*
use the STL.  This is the first step in removing the STL from the C++
bindings (Solaris has 2 versions of the STL; if OMPI uses one and an
MPI application wants to use another, Bad Things happen).

The main idea is to wrap up the C++ callback function pointers and the
user's extra_state into our own struct that is passed as the
extra_state to the C keyval registration along with the intercept
routines in intercepts.cc.  When the C++ intercepts are activated,
they unwrap the user's callback and extra state and call them.

It got a little more complicated than that, however:

 * I realized that we were returning errors back from
   Comm::create_keyval() incorrectly, so I fixed that.
 * Instead of using STL maps to store associations, we now use an
   opal_list_t which has to be guaranteed to be initialized correctly
   and only once in a multi-threaded environment.
 * Because of whackyness in the C++ bindings, it is possible to call
   Comm::Create_keyval with C callbacks (!).  If both registered
   callbacks are C functions, then ensure to avoid all the C++
   machinery.

This commit was SVN r17125.
2008-01-12 13:20:38 +00:00
Jeff Squyres
260f1fd468 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-08 23:50:04 +00:00
Brian Barrett
1ba97181dc A number of MPI-2 compliance fixes for the C++ bindings:
* Added Create_errhandler for MPI::File
  * Make errors_throw_exceptions a first-class predefined exception
    handler, and make it work for Comm, File, and Win
  * Deal with error handlers and attributes for Files, Types, and Wins
    like we do with Comms - can't just cast the callbacks from C++
    signatures to C signatures.  Callbacks will then fire with the
    C object, not the C++ object.  That's bad.

Refs trac:455

This commit was SVN r12945.

The following Trac tickets were found above:
  Ticket 455 --> https://svn.open-mpi.org/trac/ompi/ticket/455
2006-12-30 23:41:42 +00:00
Jeff Squyres
0a28212392 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 17:34:12 +00:00
Jeff Squyres
5f96a74e33 Make user-defined MPI::Op's be thread safe (the previous
implementation was not thread safe).  See lengthy comment in
ompi/mpi/cxx/intercepts.cc::ompi_mpi_cxx_op_intercept() for a full
explanation.

This commit was SVN r8606.
2005-12-23 16:49:09 +00:00
Jeff Squyres
4a061b7c78 Since all of the collectives (except scan and exscan) are defined on
both intercomm and intracomm, put them up in MPI::Comm rather than
duplicating them in MPI::Intercomm and MPI::Intracomm.

This commit was SVN r8583.
2005-12-21 21:12:52 +00:00
Jeff Squyres
83d34c8435 - Remove some dead code
- Fix some typos from last commit
- Add collectives of intercommunicators
- Move the static current_op member from Intracomm to Comm
  --> this is still a remaining problem: the global variable
      current_op is not thread safe!

This commit was SVN r8520.
2005-12-15 22:07:34 +00:00
Jeff Squyres
42ec26e640 Update the copyright notices for IU and UTK.
This commit was SVN r7999.
2005-11-05 19:57:48 +00:00
Brian Barrett
39dbeeedfb * rename locking code from ompi to opal
This commit was SVN r6327.
2005-07-03 22:45:48 +00:00
Jeff Squyres
4ab17f019b Rename src -> ompi
This commit was SVN r6269.
2005-07-02 13:43:57 +00:00