You'll acquire CPU 0's lock (since a map lookup with an invalid key yields the zero value). I agree this isn't optimal when you change the affinity of a process after it has started. You could imagine a scheme where, if this happens, you create a new lock, but that would significantly complicate the scheme as you would now potentially need to take a read lock on the map in case it changes under you. It's annoying that CPUID values aren't guaranteed to be without holes, but that's what we're stuck with.

Yeah, the sleep is a leftover from an earlier version of the code that didn't use sched_setaffinity. I've remove it now.