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

Question

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

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

我有几个问题。

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

2. 在目前有 300 个线程等待条件变量的方法中，每秒 signaled N * H * 3 次，很可能成为可扩展性的瓶颈(尤其是在调用 signal 的那一边)。有没有更好的方法可以让每个任务只唤醒一个工作人员？

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

感谢您的建议!

Answer 1

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

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

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

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