boost::interprocess 32 和 64 位进程之间的共享内存

问题描述

我正在尝试让 boost::interprocess 在 32 位和 64 位进程之间共享内存.这个错误跟踪器条目表明这在 Boost 1.49 中是可能的，这就是我用.

I'm trying to get boost::interprocess to share memory between 32 bit and 64 bit processes. This bug tracker entry suggests that this might be possible in Boost 1.49, which is what I use.

作为测试，我尝试共享一个无符号整数.这是一个带有两个按钮的简单 Qt 应用程序.

As a test I tried sharing an unsigned int. It's a simple Qt application with two buttons.

#define SHARED_MEMORY_NAME "My shared memory"
#define SHARED_VAR_NAME "testVar"
namespace bip = boost::interprocess;

void on_createMemButton_clicked()
{
  std::cout << "sizeof(unsigned int): " << sizeof(unsigned int) << std::endl;
  bip::shared_memory_object::remove(SHARED_MEMORY_NAME);
  bip::managed_shared_memory mem(bip::create_only, SHARED_MEMORY_NAME, 12345);
  mem.construct<unsigned int>(SHARED_VAR_NAME)(42);
  std::cout << "Created shared memory " << SHARED_MEMORY_NAME << std::endl;
}

void on_accessMemButton_clicked()
{
  try
  {
    std::cout << "sizeof(unsigned int): " << sizeof(unsigned int) << std::endl;
    bip::managed_shared_memory mem(bip::open_only, SHARED_MEMORY_NAME);
    std::pair<unsigned int*, size_t> p = mem.find<unsigned int>(SHARED_VAR_NAME);
    std::cout<< "got " << p.second << " numbers " << std::endl;
    if (p.second > 0)
      std::cout << "first number is: " << *p.first << std::endl;

    bip::shared_memory_object::remove(SHARED_MEMORY_NAME);
  }
  catch (bip::interprocess_exception e)
  {
    std::cout << "Shared mem " << SHARED_MEMORY_NAME << " not found" << std::endl;
  }
}

如果我从具有相同位数的进程创建或访问共享内存，它可以毫无问题地工作.但是如果我在 64 位进程中创建内存，并从 32 位进程中读取，该进程进入 managed_shared_memory::find() 函数并且永远不会回来.如果我反过来尝试，64 位进程再次在 managed_shared_memory::find() 中失败，这次是访问冲突.使用 managed_windows_shared_memory 产生了相同的结果.

If I create or access the shared memory from processes with the same bitness it works without problems. But if I create the memory in a 64 bit process, and read from a 32 bit process, the process enters the managed_shared_memory::find() function and never comes back. If I try it the other way round, the 64 bit process fails in managed_shared_memory::find() again, this time with an access violation. Using managed_windows_shared_memory yielded the same results.

有什么办法可以让这个工作吗?

Is there any way to make this work?

推荐答案

我遇到了同样的问题.我在另一个进程中运行了一个 DLL，并单独编译了一个控制器应用程序.我的 find() 和 find_or_construct() 会挂起，使它看起来像一个死锁.更改为 null_mutex_family 什么也没做.

I had the same problem. I had a DLL running inside another process and a controller app compiled separately. My find() and find_or_construct() would hang, making it look like a dead lock. Changing to null_mutex_family did nothing.

问题原来是用于编译 DLL 与控制器应用程序的字符类型.将两者都设置为使用多字节字符为我修复了它(使用 MSVC).

The problem turned out to be the char type used to compile the DLL vs. the controller app. Setting both to use Multi-Byte chars fixed it for me (using MSVC).

我将这一行添加到我的代码中，这样它就永远不会在访问我的 managed_shared_memory 实例之前再次像这样咬我.

I added this line to my code so that it will never, ever bite me like that again, right before accessing my managed_shared_memory instance.

if (sizeof(char) != 2) throw std::exception("Set your chars right");

如果您尝试从使用另一种类型的应用程序中查找和使用一种类型的字符构造的对象，boost 将陷入无限循环(我没有耐心尝试找到).

If you try to find and object constructed with one type of char, from an app using another type, boost will hang in an endless loop (that I have not had the patience to try and find).

这篇关于boost::interprocess 32 和 64 位进程之间的共享内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！