To get a handle on how this works you need a little understanding of how operating systems schedule processes/threads. I'm very rusty on this but I'll have a go. My background is UNIX, but the principles will be the same for modern Windows (ie NT onwards). I'll refer to processes here, but you can substitute the word threads more or less interchangeably.
On a single CPU machine only one process can be running at any given time. Call it's state RUNNING. Other processes may be ready to run (RUNNABLE) ie waiting for the CPU or waiting for an I/O event such as arrival of data on a network interface, data from a disk read, input from mouse or keyboard etc (SLEEPING).
When a hardware interrupt occurs due to completion of an IO request (eg disk read), or a timer interrupt occurs (time slice expired) the OS will determine if a context switch is needed by examining the queue of RUNNABLE processes and determine (using priority and 'fairness' algorithms) if one of the currently RUNNABLE processes should replace the currently RUNNING process. If a context switch is needed, the currently running processes context is saved (eg CPU registers including the stack pointer and program counter (aka instruction pointer)) and the context of another runnable process is restored. The latter is now running and the previously running process goes onto the runnable queue.
In a multiple CPU (eg dual core) machine, it is much the same, except the OS distributes the runnable processes across multiple CPUs.
When the OS performs a context switch, it's scheduling algorithm determines which is the next process to run according to priority, how long it has been waiting etc. The scheduler guarantees that all processes will be eventually run. One process cannot hog a CPU.
In summary.....
1. The OS maintains a queue of RUNNABLE processes.
2 When an interrupt occurs the OS makes a context switch saving the context of a currently running process and restoring that of a RUNNABLE process. Which RUNNABLE process to run is chosen by the scheduler.
3. The mechanism is the same for single or multiple CPUs. These are SMP (symmetrical Multi Processing) machines so the selection of which CPU to run a process on should be round robin.
4. An application cannot override this mechanism and hog any CPU indefinitely.
5. The scheduler acknowledges both priority and 'fairness'.
So the answer to the original question is basically both cores should be used 'efficiently'. I assume that SMP (ie dual core) support would have been present in Windows from NT onwards and designed in from the beginning.
