提升进程间 managed_mapped_file 发现失败

Posted 2023-02-21

【中文标题】提升进程间 managed_mapped_file 发现失败

【英文标题】：boost interprocess managed_mapped_file find failing

【发布时间】：2015-02-09 15:25:49

【问题描述】：

我正在尝试使用 Boost 中的进程间共享跨进程的结构。

我已将映射文件定义为使用空互斥锁，因为我在锁定它时遇到问题，我不介意自己进行同步。

我遇到的问题是寻找对象。

我有以下声明：

typedef boost::interprocess::basic_managed_mapped_file
    < char,
    boost::interprocess::rbtree_best_fit<boost::interprocess::null_mutex_family,boost::interprocess::offset_ptr<void>>,
    boost::interprocess::flat_map_index>
    my_mapped_file;

在流程 A 中，我这样做：

m_managedMappedFile.reset(new my_mapped_file(bip::open_or_create, filename, filesize));
auto hdr = m_managedMappedFile->find_or_construct<Foo>(bip::unique_instance)();
auto x = m_managedMappedFile->find<Foo>(bip::unique_instance);

正如我所料，它找到了对象。现在，在进程 B 中：

    m_managedMappedFile.reset(new my_mapped_file(bip::open_only, filename));
    auto ret = m_managedMappedFile->find<Foo>(bip::unique_instance);

由于某种原因，find 方法在进程 B 中返回 null。我意识到我一定在做一些愚蠢的事情，但无法弄清楚。

谁能帮忙？

【问题讨论】：

你是如何锁定/同步的？因为你更清楚自己在做什么。我从来不需要绕过managed_mapped_file 级别的锁定

@sehe 如果我不使用空互斥锁，我根本无法让它工作；执行 find_or_construct(unique_instance)() 有效，但随后在另一个进程中执行 find(unique_instance)，即使进程 A 已终止，它也会挂起等待互斥锁（在 priv_generic_find 中）！

平台、库/编译器版本是什么？

这是问题所在 - 请参阅下面接受的答案

【参考方案1】：

您不必绕过默认bip::managed_mapped_file 索引的锁定机制。

看看你是否可以成功运行以下命令：

#include <iostream>
#include <boost/interprocess/managed_mapped_file.hpp>

namespace bip = boost::interprocess;

struct X 
    int i;
;

int main()

    
        bip::managed_mapped_file f(bip::open_or_create, "/tmp/mmf.bin", 1ul << 20);

        if (!f.find<X>(bip::unique_instance).first) 
            auto xp = f.find_or_construct<X>(bip::unique_instance)();

            assert(xp);
            xp->i = 42;
        
    

    
        bip::managed_mapped_file f(bip::open_only, "/tmp/mmf.bin");
        auto xp = f.find<X>(bip::unique_instance).first;

        if (xp)
            std::cout << "value: " << xp->i++ << "\n";
    

这应该在第一次运行时（或在文件重新创建后）打印42，并在每次后续运行时增加数字。

我将看一下段管理器的unique_instance_t* 重载背后的实现，但我怀疑它们可能无法工作，因为互斥策略被取消了。不过，目前这只是一种预感。

我会专注于找出为什么不能让 Interprocess managed_mapped_file 在您的平台和安装上以默认配置工作。

【讨论】：

非常感谢您的帮助 - 我正在为您获取编译​​器/库版本，我意识到我的主应用程序是 64 位的，而我的测试应用程序是 32 位的 - 那（可以理解）令人困惑的事情。再次感谢！

这确实是有道理的，因为看起来至少因为here unique_instance_t 方法使用了typeid(T).name() 这将是不同的:)

（实际上是这样。在具有不同 ABI 的进程之间共享 C++ 类将只是未定义的行为。我认为 Boost Interprocess 不会检测到并避免它）