Is it really impossible to suspend two std/posix threads at the same time?

Question

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.

Answer 1

I want to suspend them when the CPU temperature rises above a threshold.

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.

In other words, the tasks take too long to complete

You could break the tasks into smaller parts, and check the semaphore more often.

A separate control thread occupies the control semaphore for a few milliseconds

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.

I've now implemented it with pthread_kill and SIGRT .

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.