When is hard-pinning threads with SetThreadAffinityMask on Windows justified, and what does it cost compared with leaving placement to the scheduler?

## What affinity actually asserts An affinity mask is a bitmask of logical processors on which a thread is *permitted* to run. `SetProcessAffinityMask` restricts every thread in a process; `SetThreadAffinityMask` restricts one thread and returns the previous mask, so it can be saved and restored. A thread's mask is always a subset of its process's, and a job object can constrain the process's mask in turn with `JOB_OBJECT_LIMIT_AFFINITY`. The key word is *permitted*. This is a hard constraint on the dispatcher. If every processor in a thread's mask is busy and eight others are idle, the thread waits. That is not a bug; it is the semantics you asked for. Everything below follows from it. ## What you give up **Idle-core utilisation.** The scheduler's default behaviour is to run a ready thread on whatever processor is available, with a preference for where it ran last so its cache stays warm. Pinning replaces "prefer" with "only", and the tail latency this produces is exactly the symptom people then blame on the scheduler. **Topology awareness you cannot encode.** A bit in a mask is a logical processor number, and that number carries no meaning by itself. It does not say whether two bits are sibling hyperthreads on one physical core — pinning two hot threads to siblings halves your throughput while looking correct. It does not say which NUMA node's memory is local, and the memory manager's page placement follows where a thread runs, so an ill-chosen mask can force every access across a node boundary. On current client hardware it does not distinguish performance cores from efficiency cores, and hardware-directed scheduling feedback exists precisely because that decision is dynamic. To pin correctly you must first query the topology with `GetLogicalProcessorInformationEx`, and then you own that logic on every future machine. **Processor groups.** An affinity mask is a `KAFFINITY`, a pointer-sized word, so it addresses at most 64 logical processors on 64-bit Windows. Larger machines are divided into processor *groups*, and a plain affinity mask applies within one group only. Code that never uses `SetThreadGroupAffinity` with a `GROUP_AFFINITY` structure — or that computes a mask from a processor count — commonly ends up confined to group 0, so a machine refresh that doubles the cores produces no speed-up at all and sometimes a regression. **Interaction with power management.** Concentrating work on a fixed subset defeats the platform's ability to park and unpark cores sensibly, and can pin a workload onto cores that are thermally constrained by neighbours. ## When pinning is genuinely justified The honest list is short, and every entry is measurement-led: - **A hot, cache-resident loop** whose working set fits in a core's private cache and where migration measurably costs more than occasional waiting. - **Latency isolation**, where a small number of critical threads must not share physical cores with bulk work — usually paired with restricting the bulk work rather than only privileging the critical threads. - **Reproducible benchmarking**, where run-to-run variance from migration hides the effect you are measuring. This is a measurement tool, not a shipping configuration. - **Per-core licensing or contractual capacity limits**, where the constraint is commercial rather than technical. - **NUMA-sensitive workloads with a large pinned working set**, where you have measured cross-node traffic and are pinning threads and memory together, not threads alone. Notably absent: "the machine has spare cores so I dedicated some to my service." Dedication by mask reserves nothing — it only forbids your threads from leaving. ## Prefer the softer mechanisms Windows offers ways to say *prefer* rather than *only*: - `SetThreadIdealProcessor` and `SetThreadIdealProcessorEx` nominate a preferred processor. The scheduler tries to honour it and freely ignores it when that processor is busy — you get cache locality without the idle-core penalty. - **CPU sets** (`GetSystemCpuSetInformation`, `SetProcessDefaultCpuSets`, `SetThreadSelectedCpuSets`, available since Windows 10 version 1607) express placement in terms the system understands and can reconcile with power management, and are the modern mechanism where affinity would once have been reached for. - **Job objects** move the constraint out of the application, so operations can set it per deployment instead of per binary. ## The governance angle The real cost of pinning is not a few percent of throughput; it is that a hardware-topology decision has been compiled into an application and will not be revisited. Machines get replaced, core counts grow, VMs get resized, and hybrid topologies arrive. A mask that was optimal on the machine it was tuned for is a silent regression on its successor, and nobody re-benchmarks it because nothing failed. So the policy a lead should own is: placement is configuration, never a constant; every pinning decision carries a recorded measurement and the topology it was measured on; prefer ideal processor and CPU sets to hard masks; and use group-aware APIs unconditionally, so that today's 64-processor assumption is not tomorrow's outage. When the requirement is truly isolation, separate hardware, a separate machine, or a job-object limit is usually a better answer than a bitmask in the code.