CPU throttling in C++

I was just wondering if there is an elegant way to set the maximum CPU load for a particular thread doing intensive calculations.

Right now I have located the most time consuming loop in the thread (it does only compression) and use GetTickCount() and Sleep() with hardcoded values. It makes sure that the loop continues for a certain period and then sleeps for a certain minimum time. It more or less does the job, i.e. guarantees that the thread will not use more than 50% of CPU.
However, behavior is dependent on the number of CPU cores (huge disadvantage) and simply ugly (smaller disadvantage :)).
Any ideas?


I am not aware of any API to do get the OS’s scheduler to do what you want (even if your thread is idle-priority, if there are no higher-priority ready threads, yours will run). However, I think you can improvise a fairly elegant throttling function based on what you are already doing. Essentially (I don’t have a Windows dev machine handy):

Pick a default amount of time the thread will sleep each iteration. Then, on each iteration (or on every nth iteration, such that the throttling function doesn’t itself become a significant CPU load),

  1. Compute the amount of CPU time your thread used since the last time your throttling function was called (I’ll call this dCPU). You can use the GetThreadTimes() API to get the amount of time your thread has been executing.
  2. Compute the amount of real time elapsed since the last time your throttling function was called (I’ll call this dClock).
  3. dCPU / dClock is the percent CPU usage (of one CPU). If it is higher than you want, increase your sleep time, if lower, decrease the sleep time.
  4. Have your thread sleep for the computed time.

Depending on how your watchdog computes CPU usage, you might want to use GetProcessAffinityMask() to find out how many CPUs the system has. dCPU / (dClock * CPUs) is the percentage of total CPU time available.

You will still have to pick some magic numbers for the initial sleep time and the increment/decrement amount, but I think this algorithm could be tuned to keep a thread running at fairly close to a determined percent of CPU.