0

我有一些长期运行的操作，数以百计。目前，他们每个人都在自己的线程上。我使用线程的主要目标不是加快这些操作。在这种情况下，更重要的是它们似乎同时运行。

我知道协作式多任务处理和光纤。但是，我试图避免任何需要在操作中接触代码的事情，例如在它们中添加yieldToScheduler(). 我也不想规定这些例程被程式化以被编码以发出一口大小的任务项队列......我想将它们视为黑匣子。

目前我可以忍受这些缺点：

  • 最大线程数往往为 O(1000)
  • 每个线程的成本是 O(1MB)

为了解决由于上下文切换导致的糟糕缓存性能，我确实有一个计时器的想法，它可以调整优先级，使得只有IdealThreadCount()线程处于正常优先级，所有其余线程都设置为空闲。这会让我扩大时间片，这意味着更少的上下文切换并且仍然可以满足我的目的。

问题1：这是个好主意吗？一个肯定的缺点是它不能在 Linux 上工作（文档说不QThread::setPriority()在那里）。

问题2：还有其他想法或方法吗？QtConcurrent 是否在考虑这种情况？

（一些相关阅读：how-many-threads-does-it-take-to-make-them-a-bad-choice，many-threads-or-as-few-threads-as-possible，maximum-number-of -threads-per-process-in-linux )

4

2 回答 2

0

已经6个月了，所以我要关闭它。

首先，我要说线程有多个目的。一是加速……在多核机器时代，很多人都在关注这一点。但另一个是并发性，即使从整体上看它会减慢系统速度，它也是可取的。然而并发可以使用比线程更轻量的机制来实现，尽管它可能会使代码复杂化。

因此，这只是程序员便利性与用户体验之间的权衡必须调整以适应目标环境的情况之一。这就是在 Mosaic 时代，谷歌使用 Chrome 处理每个选项卡的方法是不明智的（即使在其他条件相同的情况下，进程隔离更可取）。如果操作系统、内存和 CPU 不能提供良好的浏览体验……他们现在不会那样做。

同样，当有独立的操作要并发时创建很多线程，可以省去你坚持自己的调度器和yield()操作的麻烦。这可能是表达代码的最简洁的方式，但如果它阻塞了目标环境，那么需要做一些不同的事情。

所以我想我会确定，将来当我们的硬件比现在更好时，我们可能不必担心我们制作了多少线程。但现在我将根据具体情况进行处理。即，如果我有 100 个并发任务类 A，10 个并发任务类 B，3 个并发任务类 C……那么将 A 切换到基于光纤的解决方案并给它一个由几个线程组成的池可能是值得的额外的并发症。

于 2010-06-07T00:30:11.847 回答
0

  1. 恕我直言，这是一个非常糟糕的主意。如果我是你，我会非常非常努力地找到另一种方法来做到这一点。您正在结合两个非常糟糕的想法：创建一大堆线程，并弄乱线程优先级。

  2. 你提到这些操作只需要看起来同时运行。那么为什么不尝试找到一种方法让它们看起来同时运行，而不是同时运行它们呢？

于 2009-12-29T05:04:24.270 回答