【问题标题】:Behavior of boost::asio::io_service thread pool during uneven loadboost::asio::io_service 线程池在负载不均时的行为
【发布时间】:2018-02-22 06:40:49
【问题描述】:

我很难弄清楚用boost::asio::io_service 构建的线程池的行为究竟如何。

documentation 说:

多个线程可以调用run()函数来建立一个池 io_service 可以从中执行处理程序的线程。 所有线程 在池中等待的都是等价的,io_service 可能 选择其中任何一个来调用处理程序。

我想,当执行run() 的线程正在执行一个处理程序时,它们会执行它,然后返回等待下一个处理程序执行。执行处理程序时,线程不被视为等待,因此不会为其分配要执行的新处理程序。那是对的吗?还是io_service 将工作分配给线程,而不考虑这些线程是否忙?

我在问,因为在我们使用的一个项目 (OSRM) 中,它使用基于 boost::asio::io_service 的线程池来处理传入的 HTTP 请求,我注意到长时间运行的请求,有时阻止其他快速请求,即使有更多线程和内核可用。

【问题讨论】:

  • 我不明白你提到的两种可能性之间的区别。两者都会在任务执行后导致阻塞。还要考虑在推送到队列时没有分配给任务的优先级(或任何类似的东西)......您如何期望io_service 在任务之间产生任何差异?
  • 如果线程很忙,并且分配了新的工作,它只有在处理完它忙的事情后才能处理新的工作项。因此,即使池中的其他线程可用,工作项也必须等待处理。在另一种可能性中,任务仅分配给非繁忙线程,因此如果有任何可用线程,工作项处理会立即开始。
  • 好的,现在我看到了问题。其实我不相信。我经常将io_service 用于线程池(我知道这不是最佳实践),但从未注意到这一点。您可以轻松地创建一个MVCE,在其中使用简单的睡眠功能演示问题,然后我们可以根据证据进行讨论。猜测图书馆的作用是徒劳的。

标签: c++ boost-asio


【解决方案1】:

在执行处理程序时,线程不会被视为等待,因此不会为其分配要执行的新处理程序。那是对的吗?

是的。这是一个拉模型队列。

一个显着的“明显”例外是使用链时:包裹在链上的处理程序确实与在同一链上运行的其他处理程序同步。

【讨论】:

猜你喜欢
  • 2011-12-18
  • 2017-09-17
  • 2016-01-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多