Boost.Asio 的同步和并发数据结构模式

Question

我正在寻找一些在 Boost.ASIO 中使用容器数据结构时应用的指导原则。 Boost.ASIO 文档描述了如何使用strand 对象来提供对共享资源的序列化访问，而无需显式线程同步。我正在寻找一种系统化的方式来将strand 同步应用于：

• STL（或类似 STL）容器（例如，std::deque、std::unordered_map）；和
• 无需等待的容器，例如boost::lockfree::spsc_queue 或folly::ProducerConsumerQueue。

下面列出了我的问题。我应该提到我的主要问题是 1-3，但有理由我也准备接受“这些问题没有实际意义/被误导”作为答案；我在问题 4 中详细说明了这一点。

1. 要使任意 STL 容器适应安全同步使用，通过 strand 实例执行其所有操作是否足够？

2. 为了使无需等待的读写容器适应同步、并发使用，是否足以通过两个不同的strands 包装其操作，一个用于读取操作，一个用于写入操作？ This question 暗示“是”，尽管在该用例中作者描述了使用 strand 来协调来自多个线程的生产者，而可能只从一个线程中读取。

3. 如果上面1-2的答案是肯定的，strand应该只是通过调用boost::asio::post来管理对数据结构的操作吗？

为了说明 3. 中的问题，这里是来自chat client example 的 sn-p：

void write(const chat_message& msg)
{
  boost::asio::post(io_context_,
      [this, msg]()
      {
        bool write_in_progress = !write_msgs_.empty();
        write_msgs_.push_back(msg);
        if (!write_in_progress)
        {
          do_write();
        }
      });
}

这里，write_msgs_ 是一个聊天消息队列。我问是因为这是一种特殊情况，对post 的调用可能会调用组合的异步操作（do_write）。如果我只是想从队列中推送或弹出怎么办？举一个高度简化的例子：

template<typename T>
class MyDeque {
public:
     push_back(const T& t);
    /* ... */
private:
    std::deque<T> _deque;
    boost::asio::io_context::strand _strand
};

那么应该MyDeque::push_back(const T& t)就打电话

boost::asio::post(_strand, [&_deque]{ _deque.push_back(t); })

其他操作也类似？还是boost::asio::dispatch 更合适？

4. 最后，我知道并发向量、哈希映射等有很多健壮的实现（例如，Intel Thread Building Blocks Containers）。但似乎在受限制的用例下（例如，只维护一个活跃聊天参与者的列表、存储最近的消息等），完全并发的向量或哈希映射的力量可能有点矫枉过正。确实是这样，还是我最好只使用完全并发的数据结构？

Answer 1

我正在寻找一种系统化的方式将链同步应用于：

• STL（或类似 STL）容器（例如，std::deque、std::unordered_map）；和

您正在寻找不存在的东西。最接近的是活动对象，除非您对它们进行异步操作，否则您几乎不需要链。这几乎是零意义，因为对 STL 容器的任何操作都不应该具有足以保证异步的时间复杂度。另一方面，计算复杂性使得添加任何类型的同步都不是最理想的 -

与细粒度锁定（在将 STL 数据结构作为 ActiveObjects 进行时自动选择）不同，使用粗粒度锁定总能获得更好的性能。

即使在设计中越早，通过减少共享比通过“优化同步”（这是矛盾的）来获得更高的性能。

• 免等待容器，例如 boost::lockfree::spsc_queue 或 folly::ProducerConsumerQueue。

您为什么还要同步对免等待容器的访问。无需等待意味着没有同步。

子弹

1. 要使任意 STL 容器适应安全同步使用，通过 strand 实例执行其所有操作是否足够？

   是的。只是那不是存在的东西。 Strands 包装异步任务（及其完成处理程序，它们只是来自执行程序的 POV 的任务）。

   请参阅上面的咆哮。

2. 为了使无需等待的读写容器适应同步、并发使用，将其操作包装在两个不同的链中是否足够，一个用于读取操作，一个用于写入操作？

   如前所述，同步对无锁结构的访问是愚蠢的。

   这个问题暗示“是”，尽管在那个用例中作者描述了使用一个链来协调来自多个线程的生产者，而可能只从一个线程中读取。

   这特别与 SPSC 队列相关，即在执行读/写操作的线程上放置了额外的约束。

   虽然这里的解决方案确实是创建具有对任一组操作的独占访问权限的执行逻辑线程，但注意您正在限制 任务，这是根本不同的从约束数据的角度。

3. 如果上面 1-2 的答案是肯定的，strand 是否应该通过调用 boost::asio::post 来管理数据结构上的操作？

   所以，答案不是“是”。正如我在介绍中提到的，通过post 发布所有操作的想法将归结为实现主动对象模式。是的，你可以做到这一点，不，这不会很聪明。 （我很确定如果你这样做了，根据定义，你可以忘记使用无锁容器）

   [....]
   那么 MyDeque::push_back(const T& t) 应该调用

   boost::asio::post(_strand, [&_deque]{ _deque.push_back(t); })
   

   是的，这就是 ActiveObject 模式。但是，请考虑如何实现top()。考虑一下如果您有两个 MyDeque 实例（a 和 `b）并且想要将项目从一个移动到另一个，您会怎么做：

   if (!a.empty()) {
       auto value = a.top();     // synchronizes on the strand to have the return value
       a.pop();                  // operation on the strand of a
       b.push(std::move(value)); // operation on the strand of b
   }
   

   由于队列b 不在a 的链上，b.push() 实际上可以在a.pop() 之前提交，这可能不是您所期望的。此外，非常明显的是，所有细粒度同步步骤的效率都远低于对一组数据结构进行所有操作的链。

4. [...] 但似乎 [...] 完全并发的向量或哈希映射的力量可能有点矫枉过正

   在完全并发的向量或哈希映射中没有“力”。他们有成本（就处理器业务而言）和收益（就降低延迟而言）。在您提到的情况下，延迟很少是问题（注册会话是一个罕见的事件，并且由实际的 IO 速度决定），因此您最好使用最简单的东西（IMO 对于那些将是单线程服务器数据结构）。让工作人员进行任何重要的操作——他们可以在线程池上运行。 （例如，如果您决定实现下棋聊天机器人）

---

您希望 strands 形成执行的逻辑线程。您希望同步访问到您的数据结构，而不是您的数据结构本身。有时，无锁数据结构是避免设计良好的简单选择，但不要指望它神奇地表现良好。

一些链接：

• boost::asio and Active Object（Tanner Sansbury on ActiveObject with Asio）有很多与您的问题重叠的想法
• How to design proper release of a boost::asio socket or wrapper thereof 是我维护连接列表的示例