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