multiple core CPU and threads

Recent operating systems know about multicore technology. Add breakpoints inside different threads and you should see concurrency (multicore or multiprocessor workstation).

valikac

There's an auto-load behavior, like Arjay said, and there's some interesting details besides.

There can be an affinity assigned to a processor, but I don't recall that threads can do that - the entire process, in Windows.

Threads have a priority, so the 'balance' depends on priority.

People seem to think a single thread runs in one CPU, but that's not actually true. If your machine were performing only one thread of activity, and it's a dual or more, you'll witness each of the CPU's doing 100 / CoreCount of the work (2 will share 50%, 4 will share 25%), give or take a few percent.

This is because when the OS scheduler slices and subsequently reschedules a thread, it has no reason to choose any particular processor - a thread can bounce around at any time. It won't be scheduled into more than one CPU at once, but as the OS slices time, the thread can spend, on average, enough time 'in' each CPU (actually, it's more accurate to say that each CPU spends enough time on the thread) - that it balances out to an average.

The more threads running, the more 'spread out' this performance is. Only if you assign processor affinity is this changed.

However, if your threads have different priorities, then it balances in favor of the higher priority threads.

An interesting side note is what is now perhaps obsolete technology that I think will return some day - hyper-threading (though I think it will be on an entirely new level with a different name).

There are multiple execution units in modern CPU's - it might seem like a parallel design, and in a way it is. Our CPU's are designed to execute multiple instructions in a stream of instructions, when those instructions are not interdependent. On average, though, there's some occasion when jumps or dependent instructions come up, that it's recognizable that only 1 or 2 execution units can be occupied. In 'standard' CPU's, this means an execution unit or two might go idle for that clock tick.

With hyperthread, the CPU can accept the next instruction of a waiting thread - and schedule unused execution units to act upon it, simulating, for a short time, a dual CPU core.

It doesn't come up often, but about %15 of the time (give or take considerably), it works out such that hyper-threading did give gains (sometimes).

Someday I think our interest in cores will change - we'll have a rank of execution units and the OS will present a collection of threads. The CPU will then dynamically choose how to schedule those threads among the execution units, such that at some times it may act like an 8 core CPU, other times a 6 core, other times a 4 core....

I have a longer post on the notion around here (two, actually).