but what if one core is already heavily loaded?
The kernel decides where and when your code will be executed. This is regardless of whether it executes in a thread or a process, it's the OSes job to manage the running of user-space code (userspace can influence which core it'll run on by setting CPU affinity, but doing that is almost never a good idea, and anyway the important decision of "when" and "how long" it'll run is governed by the OS). So, if you're on a heavily loaded system, the OS may decide to execute new threads on the same CPU as the spawning process, or on a different one. It may move a thread/process to a different core or not. These decisions depend heavily on what exactly the thread in question and other processes are doing, what priority they're running under, whether they're IO-bound or CPU-bound, whether they're interactive or not etc. The mechanism by which the decision is reached is exactly the same(*), regardless whether you're talking about threads or processes. It is also exactly the same regardless whether you're on a single-core or multi-core machine, the results may be different, but the principles are the same.
Just answering this to clear up a concrete question. I'll leave this thread now, sorry, but all this
blather talk about "resetting cores" and "security grade processors" is making my brain hurt.
(*) caveat here, it's been a while since I read up on the current Linux implementation, so there may be some difference in the kernels decision-making process, but I'm willing to bet aforementioned amount that this difference does not matter at all in the context of the current discussion.