When the OS executes threads, it starts each thread for a certain period of time (for example, 10-20 ms), then saves the state of the thread and looks for other threads to start.
Now, despite what you might think when looking at the processor usage graph, the OS actually runs a lot more threads than in your program. There are threads that run UI loops, threads that wait for I / O, threads that run background services, etc. Most threads spend most of their time blocking, waiting for something.
The reason I am talking about this is to explain that, from the point of view of the OS, the situation is more complicated than it might seem. There is a whole chain of threads performing a whole bunch of things, and the OS is trying to switch between them. Suppose you wanted to implement a heuristic that, if the thread last used all of its quantum, then the OS would do its best to schedule it in the same kernel. The OS needs to be tracked and taken into account more information, and the success of optimization may depend on many difficult to predict factors.
In addition, the advantage of thread affinity on the kernel is often almost negligible, so the OS does not try to do this automatically. Instead, they provide a function that allows the developer to explicitly indicate that a particular thread should be affinity to the kernel, and then the OS will respect the decision.
This seems like a reasonable compromise: if your thread works better when it is tied to the kernel, just ask the OS to do this. But the OS will not try to figure this out for you.
Igor ostrovsky
source share