You introduce more threads when your application will provide
benefits (faster, more intuitive, better UI, etc.) that justify the
added complexity. Do you have a specific problem to solve?
Jim ... ...
BEE MBA PMP SCJP-6
Joined: Sep 06, 2007
When Not to Use Threads
Multithreading also comes with disadvantages. The biggest is that it can lead to vastly more complex programs. Having multiple threads does not in itself create complexity; it's the interaction between the threads that creates complexity. This applies whether or not the interaction is intentional, and can result long development cycles, as well as an ongoing susceptibility to intermittent and non-reproducable bugs. For this reason, it pays to keep such interaction in a multi-threaded design simple – or not use multithreading at all – unless you have a peculiar penchant for re-writing and debugging!
Multithreading also comes with a resource and CPU cost in allocating and switching threads if used excessively. In particular, when heavy disk I/O is involved, it can be faster to have just one or two workers thread performing tasks in sequence, rather than having a multitude of threads each executing a task at the same time. Later we describe how to implement a Producer/Consumer queue, which provides just this functionality.
Modern CPUs have four cores and can run 8 threads with zero overhead.
Intel has announced a six core CPU, that runs 12 threads.
Next year, I expect that 8 and 16 core CPUs will be common.
There is no way to use all those capabilities and cores without writing multi-threaded applications.
Over time, I expect the world of hardware to split into two camps, small embedded systems, and multi-core systems that demand multi-threaded applications. The current Apple iPhone has three CPUs. My three year old laptop has two cores, my last two desktops each have quad cores.
Sequential programming is so last century
Joined: Jan 09, 2008
Pat Farrell wrote:... 8 and 16 core CPUs will be common. There is no way to use all those
capabilities and cores without writing multi-threaded applications.
Sounds like good job security for concurrent programmers.
(We'll get out of this recession yet!)