There are threaded apps and there are THREADED apps. Lots of apps spin up a few extra threads to run different app components on, like running the UI on one thread, and a database connector on another one and the rest of the app on the main thread.
That type of concurrency is simple, and intended only to prevent "blocking" behavior. Blocking behavior is what happens, for example, when: you write a simple app that runs everything on a single thread and then you: click File, Save, and, because you're saving to a really slow flash drive, it takes 4mins to save a tiny file. During that time, the entire app UI is "blocked" from receiving and processing messages from windows, like instructions to redraw itself when you open another window on top of it.
I know you've seen apps like this that get trails and remainders of other windows imprinted on them until they're done thinking. That's because the UI and the "save" function are running on the same thread, and they "take turns" (in effect) listening for user or windows input. Many apps run the UI on the main thread (the default thread you get when any process starts) and only deliberately create new threads when performing a potentially "blocking" behavior like accessing anything over a network connection or performing potentially lengthy IO routines like reading/writing big files.
Again, that type of threading is relatively easy because you aren't trying to take advantage of multiple processors (and all of the issues regarding synchronization of variables across CPUs and shit like that), you're just trying to exploit the host operating system's ability to pre-emptively multitask and schedule threads.
Your whole OS won't freeze because some jerk opens a huge file from a slow flash drive right? Of course not. It just services hardware interrupts from the device and its driver(s) when asked to, and continues to run the rest of the processes and threads that are in the queue, including your UI thread.
The next most difficult type of concurrency is when you need to split a large data processing task across as many CPUs as possible. Unlike the "blocking" problem i just illustrated, your task won't benefit at all by being split onto just one CPU. A good example is the codec for any type of encryption of compression algorithm, be it network communication (SSL), video (DIVX/XVID/MPEG), or audio (MP3/WMA/AAC). These tasks tend to have distinct start and end points, so the algorithm can identify a "load" to split into threads when more than one cpu is available, which nearly always divides the task time by the number of available CPUs.
One thing that dual cpu configurations are really good at is servicing hardware interrupts. So doing things like burning CDs and scanning and ripping videos to disk works a lot better when you have more than one cpu or core.
Facebook
Twitter
Instagram