用于服务网络连接的英特尔 TBB 任务 - 好模型？

Question

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

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

我有几个问题。

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

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

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

感谢您的建议！

Answer 1

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

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

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

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