我有一些长期运行的操作，数百个。目前他们各自都在自己的线程上。我使用线程的主要目标是不来加速这些操作。在这种情况下，更重要的是它们似乎同时运行。
我知道合作多任务处理和光纤。但是，我试图避免任何需要触摸操作中的代码的内容，例如用yieldToScheduler()之类的东西加油。我也不想规定这些例程被编程为编码以发出一口大小的任务项的队列......我想将它们视为黑盒子。
目前我可以忍受这些缺点：
为了解决由于上下文切换导致的错误缓存性能，我确实想到了一个计时器，它会处理优先级，只有idealThreadCount()个线程处于Normal优先级，其余的都设置为Idle 。这会让我扩大时间片，这意味着更少的上下文切换，仍然可以用于我的目的。
问题＃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）
答案 0 :(得分：0)
恕我直言，这是一个非常糟糕的主意。如果我是你，我会尝试真的，很难找到另一种方法来做到这一点。你要结合两个非常糟糕的想法：创建一个卡车负载的线程，并搞乱线程优先级。
您提到这些操作只需出现即可同时运行。那么为什么不尝试找到一种方法让它们出现同时运行，而不是同时运行它们呢？
答案 1 :(得分：0)
已经6个月了，所以我要关闭它。
首先，我会说线程服务于多个目的。一个是加速 ......在多核机器时代，很多人都在关注它。但另一个是并发，即使从整体上看它减慢系统速度也是可取的。然而，并发性可以使用比线程更轻量级的机制来实现，尽管它可能使代码复杂化。
因此，这只是必须调整程序员方便性与用户体验的权衡以适应目标环境的情况之一。这就是谷歌在使用Chrome时采用每个标签的流程的方法在Mosaic时代是不明智的（即使流程隔离更可取，其他条件相同）。如果操作系统，内存和CPU无法提供良好的浏览体验......他们现在不会这样做。
类似地，当您希望并行执行独立操作时创建大量线程可以避免在自己的调度程序和yield()操作中遇到困难。它可能是表达代码的最简洁方式，但如果它扼杀了目标环境，那么就需要做一些不同的事情。
所以我想我会明白，在将来当我们的硬件比今天更好的时候，我们可能不必担心我们制作了多少线程。但是现在我会根据具体情况来看待它。即如果我有100个并发任务类A，10个并发任务类B和3个并发任务类C ...然后将A切换到基于光纤的解决方案并给它一个几个线程池可能是值得的额外的复杂性。