Why set the ProcessorAffinity for a thread?

Question

I've been unable to find a good explanation as to why a multithreaded executable would want to set the ProcessorAffinity per thread. To me, it seems like this is trying to override the CLR/Operating system; something I don't think I'm smart enough to be doing.

Why would I want to get involved in setting the ProcessorAffinity for threads on a multi-core system?

Answer 1

If you tell a thread to run with a non-set affinity, then it'll be allowed to run on any core. This means however, that when one core is busy, it'll move your thread onto a different core, this stopping and possible moving is called a Context Switch. In most cases you'll never notice it, however, in cases like gaming consoles, context switch's can be a surprisingly expensive process.

In these cases it might be better to move something like the audio loop and the video loop onto "private" core's where they are locked to that core, and as such won't switch, giving possible optimisations.

Answer 2

Only very specific types of applications really benefit from the use of manual thread affinity, mostly applications with long running parallel processes. I could imagine it being used in virus scanners, or math heavy applications like Seti@Home.

Another theoretical advantage is that the processor can make use of its cache if you have small processes that run multiple times. But again, in reality you'd need a really specific type of application to make the difference noticable.

I have never had the need to bother with it. Usually the operating system knows best.

Answer 3

Processor caching.

And can use it to throttle.
Might have lower priority process that you don't want to dominate.
On a 4 processor machine could limit it to one processor.
Throttle can also be done with thread priority.
Would only use this if the process benefits from caching.
I like it because in task manager I can see it hammering one CPU.