我有一个带有主线程和诊断线程的程序。主线程基本上是一个执行各种任务的while(1)循环。其中一个任务是为诊断引擎提供有关系统的信息，然后稍后（即在下一个循环中）检查以查看是否存在应该处理的任何问题。主循环的迭代不应超过0.1秒。如果一切顺利，那么诊断引擎几乎没有时间回来回答。但是，如果出现问题，诊断引擎可能需要几秒钟来隔离问题。因此，每次诊断引擎收到新信息时，它都会启动一个新的诊断线程。
我们遇到的问题是诊断线程正在偷走主线程的时间。实际上，即使我们有两个线程，主线程也不能像我想的那样经常运行，因为诊断线程仍在旋转。
使用Boost线程，是否可以限制线程在转移到另一个线程之前可以运行的时间？这里重要的是我们使用的诊断算法是blackbox，所以我们不能在其中加入任何线程代码。谢谢！
答案 0 :(得分：2)
看起来你的线程是互锁的，所以你的主线程一直等到后台线程完成它的工作。检查可能导致此问题的任何多线程同步。
检查它与操作系统调度无关，运行你在双核系统上编程，所以两个线程都可以真正并行执行
答案 1 :(得分：1)
如果您运行多个线程，它们确实会占用CPU时间。如果您只有一个处理器，并且一个线程正在执行处理器密集型工作，那么该线程将减慢在其他线程上完成的工作。如果使用特定于操作系统的工具来更改线程优先级，则可以使诊断线程的优先级低于主线程。另外，您提到诊断线程正在“旋转”。你的意思是它确实具有相当于这样的旋转等待：
while(!check_done()) ; // loop until done
如果是这样，我强烈建议您尝试避免这种忙碌等待，因为它会消耗CPU时间而不会实现任何目标。
但是，虽然多个线程可以导致彼此减速，但如果您看到实际延迟几秒钟，则表明存在另一个问题，并且主线程实际上正在等待诊断线程完成。检查诊断线程对join()的调用是否在主循环之外。
另一种可能性是诊断线程正在锁定主线程循环所需的互斥锁。检查哪些互斥锁被锁定以及在哪里。
要真正提供帮助，我需要查看一些代码。
答案 2 :(得分：0)
从您提出问题的方式来看，您似乎并不确定线程的工作方式。我假设“在转移到另一个线程之前线程可以运行的时间量”是指每个线程花费的cpu周期数。这种情况每秒发生数十万次。
Boost.Thread不支持线程优先级，尽管您的操作系统特定的线程API会。但是，您的问题似乎表明需要进行基本的重新设计 - 或者至少需要进行大量的分析才能找到瓶颈。
答案 3 :(得分：0)
你通常不能在操作系统级别这样做，所以我怀疑boost有什么特定的限制执行时间。你可以用小块操作来伪装它并等待，但它不干净。
我建议在线程或进程级别查找处理器关联（这将是特定于操作系统的）。如果您可以将诊断处理与多核计算机上的[逻辑]处理器的有限子集隔离，它将为您提供一种非常可靠的机制来控制相对于主进程的最大执行量。这是我在尝试做类似事情时发现的最佳解决方案。
希望有所帮助。