用于多线程支持的Strandify内部协作对象

Question

我当前的应用程序拥有多个可激活的对象*。我的意图是在同一个io_context中“运行”所有这些对象，并添加必要的保护，以便从单个线程切换到多个线程(使其可伸缩)。

如果这些对象完全独立于其他对象，那么运行关联io_context的线程数量就会平稳增长。但是由于这些对象需要协作，因此应用程序在多线程中崩溃，尽管每个对象中都存在串。

假设我们有A和B类型的对象，它们都由相同的io_context提供服务。这些类型中的每一种都运行异步操作(计时器和套接字--它们的处理程序被bind_executor(strand, handler)包围)，并且可以根据通过套接字接收到的信息构建缓存并将操作提交给它们。A类型的对象需要从B的多个实例中获取缓存的信息，以便执行它们自己的工作。

是否可以通过使用链(而不添加显式互斥保护)来访问这些信息?如果是的话，如何访问？

如果没有，可以采取什么策略来实现可伸缩性？

我已经试过玩期货游戏了，但这种策略无疑会导致僵局。

谢谢

(*)在术语上可能我错了:对象获得对io_context的引用并拥有自己的链，所以我认为它们是可激活的，因为它们没有真正的运行线程

Answer 1

你把含糊的话混在一起了。“可激活”、"Strandify“、”相互合作“。它们都接近有意义的概念，但狭义地避免与任何精确的含义相结合。

解构

让我们简化使用更精确的概念。

假设我们有A和B类型的对象，它们都由相同的io_context服务

我认为说“A型和B型有相关联的遗嘱执行人”更有成效。当您确保A和B上的所有操作都是从该执行器操作，并且确保该执行器序列化访问时，则基本上可以得到活动对象模式。

可以根据通过套接字接收的信息并向其发布操作来构建缓存。

这很有趣。我认为这意味着您不会直接调用类的成员，除非他们将实际执行推迟到strand。同样，这将是活动对象。

然而，你的症状表明，并不是所有的手术都是“张贴在他们的”。这意味着它们在任意线程上运行，从而导致您的问题。

是否可以通过使用链(而不添加显式互斥保护)来访问这些信息?如果是的话，如何访问？

你问题的关键就在这里。数据依赖关系。它也是;ole;y将限制缩放的有用性，当然，除非生成要从其他线程检索的信息是一项计算开销很大的操作。

但是，根据短语_“从B‘的多个实例中获取缓存的信息”表明，数据实际上是瞬时的，您只需支付跨线程访问的同步成本。

问题

Q.是否可以通过使用链(而不添加显式互斥保护)来访问这些信息?如果是的话，如何访问？

严格来说是的。通过确保所有的操作都继续进行，这些对象就变成了真正的活动对象。

然而，有一个重要的警告:链不是零成本。只有在特定的上下文中才能对它们进行优化(例如，在立即的延续中，或者当执行上下文没有并发性时)。

但在所有其他情况下，它们以与互斥相同的代价结束同步。strand的目的不是要删除锁争用。相反，它允许以声明的方式指定任务的同步要求，这样，无论异步完成的方法(使用回调、未来、协同、辅助任务等)或所选的执行上下文，都可以正确同步相同的代码。

示例:我最近发现了一个生动的例子，说明了串同步的成本，即使在一个简单的上下文中(在这里，串行执行已经得到了隐式保证)： 圣玛15，23:08哦酷。这些股是没有必要的。我把它们加起来是为了安全，直到我知道没有它是安全的。在本例中，异步调用链形成逻辑链(不存在计时器或全双工套接字，因此都是线性的)。那个..。改进了这种情况:)现在的吞吐量是3.5gbps，即使使用1024字节的服务器缓冲区，吞吐量也从删除链增加了7倍。

Q.，如果不是，可以采取什么策略来实现可伸缩性？

我怀疑你真的想要包含shared_futures的缓存。因此，第一次检索将结果的未来放在缓存中，随后的检索将立即获得已经存在的共享未来。

如果您确保缓存查找数据结构是线程安全(可能带有读取器/写入器锁(shared_mutex) )，则可以以最小的开销从任何参与者访问它，而不需要遍历每个生产者的各个链。

记住，等待期货是一种阻碍行动。因此，如果您通过发布在执行上下文中的任务来执行这个任务，那么您可能很容易就没有线程了。在这种情况下，最好以boost::asio::async_result或boost::asio::async_completion的形式提供boost::asio::async_result，这样您就可以以非阻塞的方式等待。