同时悬挂两个STD/POSIX线程真的不可能吗？
我想简要暂停在Linux上运行的多个C ++ STD线程。 OS似乎不支持这一点。
这些线程处理的任务需要花费不平衡且不可预测的时间（几秒钟）。 当CPU温度上升到阈值以上时，我想悬挂它们。 检查任务中的悬架是不切实际的，仅在任务之间。
我想让所有工人暂停几毫秒的操作。 那怎么办？
我目前正在做的事情，
我目前正在使用细长的自定义二进制信号量类（想想C ++ 20信号）中的条件变量。 工人通过获取并立即释放信号量来开始下一个任务之前先检查悬架。 如果温度太高，单独的控制线将占据控制信号量的几毫秒。 这通常效果很好，并且CPU温度稳定。
我不太在意悬挂线程的稍微延迟。 但是，当一项任务花费比另一个任务更长时，其线程将继续单独运行。 这激活了CPU涡轮模式，这与我想要实现的相反（它相对效率低，因此对热效应不利）。 由于无法控制硬件，因此我无法停用CPU涡轮增压器。 换句话说，任务花费太长时间了。 所以我想从外面有力地停下来。
I want to briefly suspend multiple C++ std threads, running on Linux, at the same time.
It seems this is not supported by the OS.
The threads work on tasks that take an uneven and unpredictable amount of time (several seconds).
I want to suspend them when the CPU temperature rises above a threshold.
It is impractical to check for suspension within the tasks, only inbetween tasks.
I would like to simply have all workers suspend operation for a few milliseconds.
How could that be done?
What I'm currently doing
I'm currently using a condition variable in a slim, custom binary semaphore class (think C++20 Semaphore).
A worker checks for suspension before starting the next task by acquiring and immediately releasing the semaphore.
A separate control thread occupies the control semaphore for a few milliseconds if the temperature is too high.
This often works well and the CPU temperature is stable.
I do not care much about a slight delay in suspending the threads.
However, when one task takes some seconds longer than the others, its thread will continue to run alone.
This activates CPU turbo mode, which is the opposite of what I want to achieve (it is comparatively power inefficient, thus bad for thermals).
I cannot deactivate CPU turbo as I do not control the hardware.
In other words, the tasks take too long to complete.
So I want to forcefully pause them from outside.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常，这将购物车放在马面前。
正确设计的硬件应具有足够的冷却，以最大程度地负载，并且您的程序不应超过该冷却能力。
此外，由于您在谈论涡轮增压器，因此我们可以假设一个Intel CPU，它会自行进行热门油门，从而使您的程序运行得较慢而无需您做任何事情。
您可以将任务分解为较小的部分，并更频繁地检查信号量。
，您的硬件真的不太可能对毫秒延迟做出反应 - 对于任何热量来说，这太短了。当温度升高并接近限制时，您可能会更好地监视温度，并简单地减少所计划的任务数量。
请注意，将线程悬挂在未知状态（信号收到时目标任务正在执行的内容）都是僵局的食谱。该任务可能在
malloc内部，可能是保留任意锁，等等。等等。您的控制线程必须仅执行直接系统调用，不得呼叫
libc等。此解决方案是不可能测试的，并且无法正确实现。
In general, that is putting the cart before the horse.
Properly designed hardware should have adequate cooling for maximum load and your program should not be able to exceed that cooling capacity.
In addition, since you are talking about Turbo, we can assume an Intel CPU, which will thermally throttle all on their own, making your program run slower without you doing anything.
You could break the tasks into smaller parts, and check the semaphore more often.
It's really unlikely that your hardware can react to millisecond delays -- that's too short a timescale for anything thermal. You will probably be better off monitoring the temperature and simply reducing the number of tasks you are scheduling when the temperature is rising and getting close to your limits.
Note that suspending threads in unknown state (whatever the target task was doing at the time of signal receipt) is a recipe for deadlocks. The task may be inside
malloc, may be holding arbitrary locks, etc. etc.If your "control thread" also needs that lock, it will block and you lose. Your control thread must execute only direct system calls, may not call into
libc, etc. etc.This solution is ~impossible to test, and ~impossible to implement correctly.