So what happens when you find yourself running on a CPU that wasn't in your initial affinity mask?
Also, the "sleep for 1 ms" approach used in `init()` looks wrong -- if `sched_setaffinity()` doesn't guarantee that the calling task has been migrated to one of the target CPUs on return (which I suspect it does), I don't think sleeping for a millisecond is going to change anything.
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.