【问题标题】:move boost::interprocess::string in shared memory在共享内存中移动 boost::interprocess::string
【发布时间】:2020-10-19 18:44:29
【问题描述】:

我想实现一些消息队列(基于向量)以某种方式处理来自网络的数据,为此我使用共享内存来保存消息,我遇到了一个与之相关的问题,问题是我的代码在我第一次运行时运行良好,当我想再次运行它时,当我想为共享内存中队列中的字符串分配一个新值时,我得到 segfaut,实际上在我想移动它的情况下(当我想复制它时存在同样的问题)。当 SSO 工作时,问题不存在,所以当我有足够小的字符串时。我做错了什么?

#include <atomic>
#include <exception>
#include <iostream>
#include <memory>
#include <string>
#include <vector>

#include <boost/interprocess/allocators/allocator.hpp>
#include <boost/interprocess/containers/string.hpp>
#include <boost/interprocess/containers/vector.hpp>
#include <boost/interprocess/managed_shared_memory.hpp>

namespace bip = boost::interprocess;

struct BadSharedMemoryAccess final : public std::exception
{
    BadSharedMemoryAccess(std::string&& msg):
        msg_{std::move(msg)}
{}

virtual const char* what() const noexcept
{
    return msg_.c_str();
}

private:
    std::string msg_;
};

struct Message
{
    bip::string message_;
};

template<typename Alloc>
class MyCustomData final
{
public:
    using allocator_type = typename Alloc::template rebind<Message>::other;

    MyCustomData(std::size_t number_of_messages, Alloc alloc = {}) :
        init_add_index_{0},
        init_handle_index_{-1},
        messages_{number_of_messages, alloc}
    {}

public:
    uint_fast64_t init_add_index_;
    int_fast64_t init_handle_index_;
    std::vector<Message, Alloc> messages_;
//    bip::vector<data::Message, Alloc> messages_;
};

template<typename DataType, typename DataAllocator>
class SharedMemory
{
public:
    template<typename... Args>
    SharedMemory(std::string const& shm_segment_name, std::size_t const segment_size,
        std::string const& shm_object_name, Args&&... args) :
            shm_object_name_{shm_object_name}
    {
        std::cout << "attempt to allocate space for shared memory segment " << shm_segment_name
              << ", size: ." << segment_size << std::endl;
        setSharedMemorySize(shm_segment_name, segment_size);

        DataAllocator const allocInstance{shm_.get_segment_manager()};
        data_ = shm_.find_or_construct<DataType>(shm_object_name.c_str())(std::forward<Args>(args)..., allocInstance);
        if (data_)
            std::cout << "shared memory segment has been allocated" << std::endl;
        else
            std::cout << "shared memory has not been constructed or founded" << std::endl;
    }

    virtual ~SharedMemory()
    {
        std::cout << "shared memory segment will be closed." << std::endl;
    }

    void setSharedMemorySize(std::string const& shm_segment_name, std::size_t const segment_size)
    {
        auto page_size = bip::mapped_region::get_page_size();
        auto const page_increase_rate{2};
        while (page_size < segment_size)
        {
            page_size *= page_increase_rate;
        }

        std::cout <<"seting page size: " << page_size << std::endl;
        shm_ = bip::managed_shared_memory{bip::open_or_create, shm_segment_name.c_str(), page_size};
        std::cout << "space for shared memory has been successfully allocated." << std::endl;
    }

    DataType& getData()
    {
        if (not data_)
            throw BadSharedMemoryAccess{"cannot access " + shm_object_name_};
        return *data_;
    }

protected:
    DataType* data_;

private:
    std::string const shm_object_name_;
    bip::managed_shared_memory shm_;
};

namespace sharable
{
    using DataAllocator = bip::allocator<Message, bip::managed_shared_memory::segment_manager>;
    template<typename Alloc>
    using DataType = MyCustomData<Alloc>;
}

int main()
{
    std::size_t const max_number_of_elements_in_container{1000000};
    auto shmem_data = std::make_shared<SharedMemory<MyCustomData<sharable::DataAllocator>, sharable::DataAllocator>>(
        "SHM_SEGMENT", sizeof(MyCustomData<sharable::DataAllocator>) +
            (max_number_of_elements_in_container * sizeof(Message) * 2),
        "SHM_CONTAINER", max_number_of_elements_in_container);

    std::vector<bip::string> feed{max_number_of_elements_in_container};
    for (std::size_t i = 0; i < max_number_of_elements_in_container; ++i)
    {
        std::string s{"blablabla11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111" + std::to_string(i)};
        feed[i] = s.c_str();
    }

    auto& data = shmem_data->getData();
    auto& shmem_vec = data.messages_;
    std::cout << "addr: " << shmem_vec.data() << std::endl;
    for (std::size_t i = 0; i < max_number_of_elements_in_container; ++i)
    {
//        if (i == 0)
//            std::cout << "msg: " << shmem_vec[i].message_ << std::endl;
        auto msg = feed[i];
        shmem_vec[i].message_ = std::move(msg);
    }
    return 0;
}

【问题讨论】:

    标签: c++ c++11 boost shared-memory boost-interprocess


    【解决方案1】:
    1. 您没有为字符串使用共享内存分配器。从这个意义上说 你的问题是一样的 circular_buffer and managed_mapped_file segmentation fault。 您可能想阅读该内容作为一般介绍。

    2. 您的示例通过将字符串包装到您自己的示例中来使事情复杂化 结构。这意味着你会得到很多繁琐的工作 分配器。对于“uses_allocator”方法 - 结合 scoped_allocator_adaptor - 可以减轻一些痛苦,例如 making non-shared copies of boost::interprocess shared memory objects.

    3. 阅读您的其余代码,我有点困惑。为什么要模板 你的SharedMemory 类型带有分配器?我的意思是,SharedMemory 应该是单点负责选择和传递权利 分配器,对吧?它如何与外部提供的分配器一起工作。

    4. 有一些未使用的 typedef,你为每个对象创建一个新段 即使它可能来自同一个共享内存(映射相同的页面 多次进入内存)。然而你不知何故认为分享很重要 拥有一个这样的实例 (make_shared)。

    5. 尺寸计算是错误的:它们只考虑了尺寸 您的 Message 结构,而不是分配的字符串数据。你好像有 忘记了映射内存也是虚拟内存。底层存储 将能够稀疏分配。那么,为什么不预留大量的 内存,用完就回复?

    6. 您正在谈论和编码(某些)移动语义,但随后您写道:

      for (std::size_t i = 0; i < max_number_of_elements_in_container; ++i) {
          auto msg = feed[i];
          shmem_vec[i].message_ = std::move(msg);
      }
      

      这很困惑。如果您这样做有什么好处(如果有效,请参见下文) 无论如何,首先制作一个明确的副本:

          auto msg = feed[i];
      
    7. 这些是令人担忧的迹象:

      uint_fast64_t init_add_index_;
      int_fast64_t  init_handle_index_;
      

      看起来您可能正计划同时使用多个 进程/线程²。在这种情况下,您必须添加同步或使用 至少atomic&lt;&gt; 类型。

    总结在我看来,您可能在努力隐藏 你不小心增加了复杂性。

    移动中

    您询问“在共享内存中移动共享字符串”。对于这部分 问题,让我们假设你实际上有你的字符串分配在共享 记忆。

    看看移动琴弦的工作原理,不难看出移动琴弦 在共享内存中的工作方式与将它们移动到堆内完全一样 会工作:对象地址会不同,但内部指针 分配的内存将是相同的。

    但是,代码做了其他事情:它不会移动内部共享 记忆。它尝试将从堆移动到共享内存。 这将 显然不安全,因为共享内存中的对象不能有用地指向 共享内存段之外的任何东西(任何其他进程都会调用 通过这样的指针间接的未定义行为)。

    通常,在 C++ 中,为了防止发生这样的事故,您有一部分是您自己的:C++11 basic_string&lt;&gt;::swap 指定

    如果Allocator 不在交换时传播并且 *this 和 other 的分配器不相等。

    移动构造函数is specified 具有复杂性:

    恒定。如果给定了alloc并且alloc != other.get_allocator(),那么线性

    请注意,复制/移动容器时分配器的语义(basic_string&lt;&gt; 是容器,类似于std::vector&lt;&gt;)涉及更多:

    做什么?

    总而言之,如果你幸运的话,移动将不会编译,因为分配器的类型不兼容并且没有提供任何类型(例如通过 uses_allocator 协议)。

    如果你不那么幸运,它会编译,但它不会(幸运地)执行移动,因为它检测到分配器“不相等”,因此它回退到复制存储。

    如果您绝对不走运,您选择了类型兼容且分配器未配置为在容器移动/复制时安全传播的配置,或者其他情况导致分配器无法检测到“不兼容”¹,并且你最终得到了 UB。

    在这种情况下,有一个更简单的选择:你知道你不能移动。因此,不要要求搬家。

    风险规避。

    治愈我们伤口的一些代码

    在分解了代码和问题中的大量复杂性之后,让我们来建设性地展示我们可以做些什么来解决问题:

    #include <exception>
    #include <iomanip>
    #include <iostream>
    #include <random>
    
    #include <boost/interprocess/allocators/allocator.hpp>
    #include <boost/interprocess/containers/string.hpp>
    #include <boost/interprocess/containers/vector.hpp>
    #include <boost/interprocess/managed_shared_memory.hpp>
    
    namespace bip = boost::interprocess;
    
    struct BadSharedMemoryAccess final : std::runtime_error {
        BadSharedMemoryAccess(std::string msg) : std::runtime_error{ std::move(msg) } {}
    };
    

    这就是前奏。现在,让我们陈述我们的意图:

    using Segment = bip::managed_shared_memory;
    template <typename U> using Alloc = bip::allocator<U, Segment::segment_manager>;
    

    这使得引用(并且可能切换出)段及其分配器变得容易。

    using Message       = bip::string;
    using Feed          = bip::vector<Message>;
    using SharedMessage = bip::basic_string<char, std::char_traits<char>, Alloc<char> >;
    using SharedFeed    = bip::vector<SharedMessage, Alloc<SharedMessage> >;
    

    只需定义我们的域实体。 通过将bip::string/bip::vector 用于堆和共享分配版本,我们可以获得两者之间的最佳互操作性;

    class MyCustomData final {
      public:
        using allocator_type = SharedFeed::allocator_type;
    
        MyCustomData(std::size_t capacity, allocator_type alloc)
            : messages_(capacity, SharedMessage(alloc), alloc) // don't brace initlaize
        { }
    
        auto&       messages()       { return messages_; }
        auto const& messages() const { return messages_; }
    
      private:
        uint_fast64_t init_add_index_ = 0;
        int_fast64_t  init_handle_index_ = -1;
        SharedFeed messages_;
    };
    

    现在,为了方便起见,删除了 virtual 析构函数和简单包装 bip::string 的 Message 结构。

    template <typename T> class SharedMemory final {
      public:
        template <typename... Args>
        SharedMemory(std::string const& shm_segment_name,
                     std::size_t const segment_size,
                     std::string const& shm_object_name,
                     Args&&... args)
            : shm_ { bip::open_or_create, shm_segment_name.c_str(), segment_size }
        {
            data_ = shm_.find_or_construct<T>
                (shm_object_name.c_str())
                (std::forward<Args>(args)...,
                 shm_.get_segment_manager())
                ;
    
            if (!data_) throw BadSharedMemoryAccess {"cannot access " + shm_segment_name + "/" + shm_object_name};
        }
    
        T const& get() const { return *data_; }
        T&       get()       { return *data_; }
    
        auto free() const { return shm_.get_free_memory(); }
      protected:
        T* data_;
    
      private:
        Segment shm_;
    };
    

    SharedMemory 有太多的责任让我感到震惊:一方面 一方面它试图成为共享对象的“智能引用”,另一方面 交给它“管理一个细分市场”。如果您真的想这样做,这会导致问题 在一个段中有多个对象。考虑拆分成Shared::Segment 和Shared::Object&lt;T&gt;。

    Feed generate_heap_feed(size_t n) {
        Feed feed;
        feed.reserve(n);
        for (size_t i = 0; i < n ; ++i) {
            feed.emplace_back(
                "blablabla11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111"
                + std::to_string(i));
        }
        return feed;
    }
    

    从main 中提取了测试提要生成器。

    int main() {
        static constexpr std::size_t capacity { 1000000 };
        static constexpr auto estimate = 300ull << 20; // 300 MiB (<< 10 kilo, << 20 mebi, << 30 gibi)
    

    用慷慨的估计取代了误导性的计算³。请参阅下面的测量值。

        using SharedData = SharedMemory<MyCustomData>;
        SharedData shmem_data("SHM_SEGMENT", estimate, "SHM_CONTAINER", capacity);
        std::cout << "Free: " << shmem_data.free() << "\n";
    

    美观且易读。在我的系统上第一次运行时打印"Free: 282572448"。

        Feed const feed      = generate_heap_feed(capacity);
        SharedFeed& shm_feed = shmem_data.get().messages();
    

    现在我们的提要并排,让我们复制:

        // copy feed from heap to shm
        auto const n = std::min(feed.size(), shm_feed.size());
        std::copy_n(feed.begin(), n, shm_feed.begin());
    
        std::cout << "Copied: " << n << "\n";
        std::cout << "Free: " << shmem_data.free() << "\n";
    

    就是这样。我们不会尝试移动,因为我们知道那是行不通的。 bip::basic_string 正确地知道如何在不兼容的分配器之间进行复制。没有汗水。

    为了更好的衡量,让我们打印一些诊断信息:

        {
            // check some random samples
            std::default_random_engine prng{std::random_device{}()};
            auto pick = [&] { return std::uniform_int_distribution<>(0, n-1)(prng); };
    
            for (auto index : {pick(), pick(), pick(), pick()}) {
                std::string_view a = feed.at(index);
                std::string_view b = shm_feed.at(index);
                std::cout << "Message #" << index
                    << (a == b? " OK":" FAIL")
                    << " " << std::quoted(b) << std::endl;
            }
        }
    }
    

    看Live On Coliru⁴

    打印,例如:

    特别注意文件大小测量(--apparent-size 与 盘)。这证实了我关于稀疏分配的观点。即使你保留 100TB,SHM_CONTAINER 的有效大小仍然是 182MiB。

    奖金部分

    作用域分配器适配器

    只需替换一行:

    template <typename U> using Alloc = bip::allocator<U, Segment::segment_manager>;
    

    与

    template <typename U> using Alloc = boost::container::scoped_allocator_adaptor<
        bip::allocator<U, Segment::segment_manager> >;
    

    成功了,解锁了神奇的分配器传播,例如从向量到 构造其元素时的字符串(使用emplace 或assign)。所以我们可以 进一步简化copy_n:

    // copy feed from heap to shm
    auto const n = std::min(feed.size(), shm_feed.size());
    std::copy_n(feed.begin(), n, shm_feed.begin());
    
    std::cout << "Copied: " << n << "\n";
    

    简单地说:

    shm_feed.assign(feed.begin(), feed.end());
    std::cout << "Copied: " << shm_feed.size() << "\n";
    

    它具有与以前完全相同的分配行为。 也可以看到 Live On Coliru。

    多态分配器 (c++17)

    这不会改变任何事情,基本上,除了:

    • 这将使 Feed/SharedFeed 和 Message/SharedMessage 共享相同的静态类型
    • 默认情况下,它将具有与以前一样的作用域分配器行为

    然而,除非我们在标准中获得对花哨指针的适当支持,否则这是一个白日梦:

    再次构造Message 结构?

    嗯。更像是“再战”。我承认我讨厌编写可感知分配器的数据类型。这无疑不是最佳的,但它是我能做的最起码的事情:

    template <typename Alloc>
    struct BasicMessage {
        // pre-c++17:
        //  using allocator_type = typename Alloc::template rebind<char>::other;
        using allocator_type = typename std::allocator_traits<Alloc>::template rebind_alloc<char>;
    
        BasicMessage(std::allocator_arg_t, allocator_type alloc)
            : _msg(alloc) { }
    
        template <typename T1, typename... T,
                 typename = std::enable_if_t<
                        not std::is_same_v<std::allocator_arg_t, std::decay_t<T1> >
                     >
            >
        explicit BasicMessage(T1&& a, T&&... init)
            : _msg(std::forward<T1>(a), std::forward<T>(init)...) { }
    
        template <typename OtherAlloc>
        BasicMessage(BasicMessage<OtherAlloc> const& other, allocator_type alloc)
            : _msg(other.message().begin(), other.message().end(), alloc) { }
    
        template <typename OtherAlloc, typename OM = BasicMessage<OtherAlloc> >
        std::enable_if_t<
            not std::is_same_v<allocator_type, typename OM::allocator_type>,
            BasicMessage&>
        operator=(BasicMessage<OtherAlloc> const& other) {
            _msg.assign(other.message().begin(), other.message().end());
            return *this;
        }
    
        template <typename OtherAlloc>
        BasicMessage(std::allocator_arg_t, allocator_type alloc, BasicMessage<OtherAlloc> const& other)
            : _msg(other.message().begin(), other.message().end(), alloc) { }
    
        BasicMessage(BasicMessage const&) = default;
        BasicMessage(BasicMessage&&) = default;
        BasicMessage& operator=(BasicMessage const&) = default;
        BasicMessage& operator=(BasicMessage&&) = default;
    
        auto& message() const { return _msg; }
        auto& message()       { return _msg; }
      private:
        bip::basic_string<char, std::char_traits<char>, allocator_type> _msg;
    };
    
    using Message       = BasicMessage<std::allocator<char> >;
    using Feed          = bip::vector<Message>;
    using SharedMessage = BasicMessage<Alloc<char> >;
    using SharedFeed    = bip::vector<SharedMessage, Alloc<SharedMessage> >;
    

    从好的方面来说,它仍然使用“魔术分配”,因为 上面介绍的 scoped_allocator_adaptor 修复。也许如果那不是我们想要的, 你可以减少一点复杂性。

    在其他地方进行了较小的界面更改:

    : messages_(capacity, SharedMessage(std::allocator_arg, alloc), alloc) // don't brace initlaize
    

    和

        std::string_view a = feed.at(index).message();
        std::string_view b = shm_feed.at(index).message();
    

    一切仍然有效,请参阅 Live On Coliru


    ¹不是标准的,因此是吓人的引号

    ² 我怀疑您可能正在尝试实施破坏者模式

    ³见Estimating size required for memory mapped boost rtree

    ⁴ 将 managed_shared_memory 替换为 manage_mapped_file 并减少容量`由于 Coliru 限制

    【讨论】:

    • 添加了奖励部分
    • 谢赫,非常感谢您的宝贵意见。只是几个问题: 1.这是否意味着我应该执行几次运行以确定我应该分配多少共享内存?因为我认为这可以配置,例如通过某些配置文件中的用户,您知道基础,例如关于最大消息数。
    • 2.如果我理解正确 boost::container::scoped_allocator_adaptor 像 pmr 一样工作?
    • 3. 只是为了好奇,当我想在 shmem 中使用字符串时,为什么我需要在你写的时候声明 bip::basic_string, allocator_type> 而不是 bip ::细绳 ?我认为 bip::string 就是为此目的而设计的。
    • @bladzio ~出于好奇~采用苏格拉底模式:3. 为什么要问bip::string,而不是bip::vector - 你在哪里做了 指定分配器?如果 bip::string 预先连接好,它会使用什么分配器?将使用哪种类型的 segment_manager 输入?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-11-05
    • 1970-01-01
    • 1970-01-01
    • 2012-11-26
    • 2015-02-14
    • 2014-11-30
    • 2012-09-06
    相关资源
    最近更新 更多