[Interprocess] managed_shared_memory problem in 64-bit windows (v. 1.48.0)
Hi,
I am trying to make a shared memory block between 2 Intel Fortran
programs and thought to use a small C/C++ lib file to accomplish this:
Fortran can use the ISO_C_BINDING module to make its pointers point to C
objects but not vice versa and there is a vast Fortran code base which
we have no intention of porting.
There is a native pipe mechanism but given the amount of data I will be
exchanging, disk access is something I want to avoid. The application is
FEM modeling and the sparse matrix can be several hundred MBs; as the
program evolves and the matrix changes, I expect hundreds of GBs of data
in total I/O. Seems like it would be better to have a shared memory
region and let the OS manage things as much as possible.
Starting small to test the idea, I am running into trouble with
something which seems easy enough to do in the examples but which only
seems to work in 32-bit. Here is an incomplete fragment (got stuck early):
#include <string>
#include
Michael, If you're trying to spin up a copy of the MUMPS solver as a separate process from within C++ using boost::interprocess, I've done that and it works on every platform. Email me at this address and I'll help you out. Damien On 20/12/2011 1:00 PM, Michel Lestrade wrote:
Hi,
I am trying to make a shared memory block between 2 Intel Fortran programs and thought to use a small C/C++ lib file to accomplish this: Fortran can use the ISO_C_BINDING module to make its pointers point to C objects but not vice versa and there is a vast Fortran code base which we have no intention of porting.
There is a native pipe mechanism but given the amount of data I will be exchanging, disk access is something I want to avoid. The application is FEM modeling and the sparse matrix can be several hundred MBs; as the program evolves and the matrix changes, I expect hundreds of GBs of data in total I/O. Seems like it would be better to have a shared memory region and let the OS manage things as much as possible.
Starting small to test the idea, I am running into trouble with something which seems easy enough to do in the examples but which only seems to work in 32-bit. Here is an incomplete fragment (got stuck early):
#include <string> #include
using namespace boost::interprocess; struct shm_remove { shm_remove(const char *input) { name = std::string(input); shared_memory_object::remove(name.c_str()); } ~shm_remove() {shared_memory_object::remove(name.c_str());} std::string name; } *remover;
extern "C" void alloc_mumps(const int n, const int nnz, const char *name) { int size_shm = sizeof(int)*(2+2*nnz) + sizeof(double)*(nnz+2*n);
remover = new shm_remove(name); managed_shared_memory managed_shm(create_only,name,size_shm);
// Trying to do the equivalent of *i = new int int *i = managed_shm.construct<int>(anonymous_instance)[1](n); }
Calling the function with n=3 and nnz=6 (a very small value compared to my final application) works OK when the application is compiled under 32-bit. Compiling under 64-bit produces an access violation error in win32_api.hpp:
inline long interlocked_compare_exchange(long volatile *addr, long val1, long val2) { return BOOST_INTERLOCKED_COMPARE_EXCHANGE(addr, val1, val2); }
values in debugger: addr=0, val1=1 val2=0.
I do not know enough about Boost to know whether this is a design limitation, a bug or just an issue with my initial build. Just for reference, this is what I used:
bjam --toolset=msvc-9.0 address-model=64 --build-type=complete stage
Any suggestions ?
Michel Lestrade Crosslight Software
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 20/12/2011 12:18 PM, Damien wrote:
Michael,
If you're trying to spin up a copy of the MUMPS solver as a separate process from within C++ using boost::interprocess, I've done that and it works on every platform. Email me at this address and I'll help you out.
Damien
That is very close to what I want to do (eventually). However, it is not a question of making 2 C++ programs communicate with each other and then using the MUMPS C interface to link against the MUMPS Fortran code. Our own app is also in Fortran. There are also some additional challenges we face in that we want to run MUMPS multiple times and have it keep its memory between calls. This is for performance reasons as the symbolic decomposition and numeric factorization can often be reused in our non-linear Newton solver. The pattern is basically 1- Symbolic decomposition 2- Numeric factorization of matrix 3- Solve 4- Load new sparse matrix which is similar to the old one 5- Try to reuse existing factorization to solve (iterative solve) 6- Redo numeric factorization if iterative solve fails. So we will run mpiexec and mumps as a detached process. For now though, I am just trying to create a shared memory object on the C++ side and have my original Fortran app have access to it. After that, the MUMPS worker program (also in Fortran) would use the same mechanism to access the shared memory. If your suggestion applies, then I am willing to try it out. Michel.
participants (2)
-
Damien -
Michel Lestrade