aspose file tools*
The moose likes Threads and Synchronization and the fly likes when not to use thread Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "when not to use thread" Watch "when not to use thread" New topic
Author

when not to use thread

abalfazl hossein
Ranch Hand

Joined: Sep 06, 2007
Posts: 635
I want to know when not to use threads?When threads make more complex the program?
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

abalfazl hossein wrote:I want to know when not to use threads?When threads make more complex the program?

Good thread use always makes a program more complex. Its a feature.
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
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
abalfazl hossein
Ranch Hand

Joined: Sep 06, 2007
Posts: 635
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.


http://www.albahari.com/threading/

What do you think?
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

abalfazl hossein wrote:What do you think?

Most of that quote is correct, or mostly correct.

Writing threaded code is harder.

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
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
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!)

Jim ... ...
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Jim Hoglund wrote:
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.


I agree. Its hard in Java and a lot of legacy languages, but until we all are using Scala or other languages designed for concurrency, its great for job security once you master it.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: when not to use thread