0

我正在为一个网络产品开发一个后端，它服务于十几个客户（N= 10-100）。每个连接需要 2 个周期性任务，即心跳和通过 SSH 下载遥测数据，每个任务的频率为HHz。还有来自前端的不同类型的额外事件。根据每个任务的性质，每个连接的套接字上都有一个等待调用的可靠部分select，这允许操作系统在等待响应时经常在线程之间切换以服务其他客户端。

在我的初始实现中，我为每个连接创建 3 个线程（心跳、遥测、额外），每个线程等待一个条件变量，每次在工作队列中有事情要做时都会被戳。工作队列使用计时器和来自前端的命令填充上述周期性事件。

我在这里有几个问题。

  1. 将工作线程池方法切换到英特尔 TBB 任务是否是个好主意？如果是这样，我需要初始化哪个线程值tbb::task_scheduler_init？

  2. 在当前有 300 个线程等待条件变量（每秒signaled次）的方法中，它很可能成为可伸缩性的瓶颈（尤其是在调用 的一侧）。有没有更好的方法让每个任务只唤醒一个工人？N * H * 3signal

  3. 如何在 TBB 中实现工作线程的唤醒？

感谢您的建议！

4

1 回答 1

1

很难说切换到 TBB 是否是一个好方法。您的性能要求是什么，当前实施的性能数字是多少？如果当前的解决方案足够好，那么它可能不值得切换。

如果您想比较两者（当前 impl 与 TBB）以了解哪个提供更好的性能，那么您可以为每个实现执行所谓的“Tracer bullet”（来自The Pragmatic Programmer书）并比较结果。简单来说，做一个简化的原型并比较结果。

正如这个答案中提到的，在没有具体证据表明您将要更改的内容会有所改进的情况下，尝试进行性能改进通常不是一个好主意。

除此之外，您可以考虑创建一个线程池，其线程数是 CPU 内核数的函数（可能是每个内核 1 或 1.5 个线程的因子）线程将从公共工作队列中取出任务. 将有 3 种类型的任务：心跳、遥测、额外。这应该可以减少使用大量线程时上下文切换造成的负面影响。

于 2012-11-05T10:59:41.043 回答