Theoretically, in a multi-tasking environment the computer with a dual core CPU will "somehow" know to direct some of the functions to each core and thus increase overall system performance. How does the system know to do this? Doesn't seem like it could be the OS... WinXP was around long before dual cores. The chipset maybe? What's the likelihood *all* of the tasks get processed by one core while the other lies dormant waiting for something to do?
This thread may clear some stuff up: http://www.elitetrader.com/vb/showthread.php?s=&threadid=55541 EDIT: Nevermind, you participated in that thread... I would think the means by which a dual core does this would be clear after reading my posts in that thread. I guess I wasn't clear.
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.
likelihood: probability almost 1, i.e. exactly like you said it: one works, the other sleeps. Of course you could write your own programs that run different threads on each processor. It might also be possible to allocate tasks to a particular processor. AFIK, this seems to be a rather theoretical possibility without much practical usage unless you start scheduling things. I haven't really heard about many people trying this.
Just off the top of my head i would suggest this about dual core. If possible wait for "VISTA". I assume the new OS will be more dual core friendly and then the new apps will follow. Intel is taking the dual, multi core route. the financial industry is still WINTEL oriented so i will follow along.