On Win32 how do you move a thread to another cpu core?

Question

I'd like to make sure that a thread is moved to a specific cpu core & can never be moved from it by the scheduler.

There's a SetThreadAffinityMask() call but there's no GetThreadAffinityMask().

The reason I need this is because high resoultion timers will get messed up if the scheduler moves that thread to another cpu.

Answer 1

You should probably just use SetThreadAffinityMask and trust that it is working.

MSDN

Answer 2

What Ken said. But if you don't trust it's working, you can call SetThreadAffinityMask again, and confirm that the return value matches what you expect the mask to be. (But then of course, if you don't trust the function then you can't trust the second call...)

Don't be confused by the existence of GetProcessAffinityMask. That function is not there to verify that SetProcessAffinityMask worked, but e.g. so you can construct a thread affinity that is a subset of process affinity.

Just look that the return value and verify that it isn't 0 and you should be fine.

Answer 3

There is no need for GetThreadAffinityMask. Just get the value of GetProcessAffinityMask, turn some bits off, then call SetThreadAffinityMask. The threads inherit the process' affinity mask, and since their affinity is under your control, you already know a thread's affinity mask (it's the one you set it to).

Answer 4

If you could call a function that returns a number indicating what CPU the thread is running on, without using affinity, the answer would often be wrong as soon as the function returned. So checking the mask returned by SetThreadAffinityMask() is as close as you're going to get, outside of kernel code running at elevated IRQL, and even that's changing.

It sounds like you're trying to work around RDTSC clock skew issues. If you are using the RDTSC instruction directly, consider calling QueryPerformanceCounter() instead:

• QueryPerformanceCounter() on Windows Vista uses the HPET if it is supported by the chipset and is in the system's ACPI tables.
• AMD-based systems using the AMD Processor Driver will mostly compensate for multi-core clock skew if you call QueryPerformanceCounter(), but this does nothing for applications that use RDTSC directly. The AMD Dual-Core Optimizer is a hack for applications that use RDTSC directly, but if the amount of clock skew is changing due to C1 clock ramping (where the clock speed is reduced in the C1 power state), you will still have clock skew. And these utilities probably aren't very widespread, so using affinity with QueryPerformanceCounter() is still a good idea.