c++ - 在共享内存中移动 boost::interprocess::string

Question

我想实现一些消息队列(基于 vector )以某种方式处理来自网络的数据，为此我使用共享内存来保存消息，但遇到了与之相关的问题，问题是我的代码有效好吧，当我第一次运行它时，当我想再次运行它时，当我想为共享内存中队列中的字符串分配一个新值时，实际上是在我想移动它时(同样的问题)当我想复制它时存在)。当 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;
}

Answer 1

您没有为字符串使用共享内存分配器。从这个意义上说
你的问题是一样的
circular_buffer and managed_mapped_file segmentation fault .
您可能想阅读它以了解一般介绍。

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

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

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

尺寸计算是错误的:它们只考虑尺寸
您的 Message struct，而不是分配的字符串数据。你好像有
忘记了映射内存也是虚拟内存。底层存储
将能够稀疏分配。那么，为什么不保留大量的
内存，当你用完时才响应？

你在谈论和编码(一些)移动语义，但是你写:

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];

这些是令人担忧的迹象:

uint_fast64_t init_add_index_;
int_fast64_t  init_handle_index_;

看起来好像您可能计划从多个同时使用这些
进程/线程²。在这种情况下，您必须添加同步或使用atomic<>至少类型。

总结 在我看来你可能非常努力地隐藏
你不小心增加了它的复杂性。
在搬家
您询问“在共享内存中移动共享字符串”。对于这部分
问题，让我们假设您实际上已将字符串分配在共享中
内存。
看看移动的弦是如何工作的，不难看出移动的弦
在共享内存中的工作方式与在堆中移动它们完全一样
会起作用:对象地址会有所不同，但指向的内部指针
分配的内存将是相同的。
但是，代码确实 别的 : 它不会在 shared 里面移动
内存。它试图移动 来自 堆 至 共享内存。 这会
显然不安全 因为共享内存中的对象不能有效地指向
共享内存段之外的任何东西(任何其他进程都会调用
通过这样的指针间接的未定义行为)。
通常情况下，在 C++ 中，为了防止这样的事故，你有一部分是你自己的: C++11 basic_string<>::swap 指定

The behavior is undefined if Allocator does not propagate on swap and theallocators of *this and other are unequal.

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

constant. If alloc is given and alloc != other.get_allocator(), then linear

请注意，复制/移动容器( basic_string<> 是容器，类似于 std::vector<> )时分配器的语义更复杂:

该怎么办？
总而言之，如果幸运的话，这个举动不会编译，因为分配器是不兼容的类型并且没有提供(例如通过 uses_allocator 协议(protocol))。
如果你不那么幸运，它会编译但它不会(幸运的是)不执行移动，因为它检测到分配器“不相等”，因此它回退到复制存储。
如果您绝对不走运，您选择了类型兼容且分配器未配置为在容器移动/复制时安全传播的配置，或者其他情况导致分配器无法检测到“不兼容”¹，您最终会与 UB。
在这种情况下，有一个更简单的选择: 你知道你不能动 .因此， 不要求搬家 .
风险规避。
一些治愈我们伤口的代码
在分解了代码和问题中的许多复杂性之后，让我们变得有 build 性并展示我们可以做些什么来解决问题:

#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_;
};

For now, dropped the virtual destructor, and the Message struct that simply wrapped a bip::string for convenience.

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_;
};

It strikes me that SharedMemory has too many responsibilities: on the onehand it tries to be a "smart-reference" for shared objects, and on the otherhand it "manages a segment". This leads to problems if you actually wanted tohave multiple objects in a segment. Consider splitting into Shared::Segmentand Shared::Object<T>.

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⁴
打印，例如:

Especially note the filesize measurements (--apparent-size vs. the size ondisk). This confirms my point about sparse allocation. Even if you reserved100TB, the effective size of the SHM_CONTAINER would still be182MiB.

奖金部分
范围分配器适配器
只需替换一行:

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> >;

有诀窍，解锁神奇的分配器传播，例如从 vector 到
构造其元素时的字符串(使用 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 共享相同的静态类型

默认情况下，它会像以前一样具有作用域分配器行为

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

polymorphic_allocator: when and why should I use it?

This is a key point and a big bummer. Arthur O'Dwyer's Towards meaningful fancy pointers paper explores the territory, as does his book "Mastering the c++17 STL"

制作 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

¹ 不是标准的，因此是恐吓报价
² 我怀疑你可能正在尝试实现 Disruptor Pattern
³ 见 Estimating size required for memory mapped boost rtree
⁴ 已更换 managed_shared_memory与 manage_mapped_file由于 Coliru 限制，容量减少