When we should use threads in our application. In other words, when should I convert a single threaded application to multi-threaded application. Being a developer, I think the task which is preventing to your application to run smoothly. That task can be handled by a thread. Like we are the getting GPS data Continuously. I think, there are other more reasons to create thread in your application. Please share your opinion.
Thanks.
A very good to reason to "convert" is that multi-cores machines are getting the norm and it's quite sad to see old programs performing badly because they're only working on one core.
I had a number crunching application where one part was really slow on a Mac with 16 virtual cores for a needed (and often called) sorting algorithm was only running on one core. I implemented my own multi-threaded sorting algorithm to adapt to the number of cores and bingo, instand amazing speedup.
Such a very unoptimized behavior can clearly seen using a CPU monitor.
So one answer to your question "when should we use thread?" is simply "when you're artificially slowing down your software by making it only run on one core".
As a side note it's very interesting because, in this example, the complexity of the sorting algo stays O(n log n ) but the "parallelization effect" gives an amazing speed boost.
Other reasons may be that in quite some cases correctly multi-threading your application, for example by using a well thought procuder/consumer scheme, can also help reduce some kind of resources contention.
The general idea is that you might benefit from using multiple threads when something can be done in parallel (and you have multiple cores to utilize.) Think embarrassingly parallel problems. The purpose here is to do more work within the same time. Read H. Sutter's articles about Effective Concurrency.
People often connect user interface responsiveness to threading. This is not necessarily the case and depends on the facilities of particular OS/framework/API, but common usage is to perform lengthy operations like file open/save in a background thread so the UI does not freeze for the duration of that action.
Another situation where threads are required is when you deal with say a vendor library that uses threads internally (messaging products, etc.) Here you have no choice but deal with threads explicitly.
Though multithreading is not rocket science, it is hard. It pays off big time to get the basics such as race conditions, deadlocks, priority inversion, and memory models strait in your head.
OldEnthusiast is quite right, taking advantage of cores is one reason to use threads. But even if you're running on older hardware that is not umpteen-core, there can still be a reason to thread. That's if you need to allow the user to keep control over the UI while your program does a lengthy task. Your program can split the task (something like processing a file, or fetching something from the network) onto a thread, and still allow the user to interact with the program, say to queue up another job.
One very good use of threading is to uncouple different problem spaces. For example, if a single thread does remote communications, user interaction, and calculations, then as the program grows a few problems can arise. The user experience can change as communications slow down or your calculations grow in processor cycle consumption.
By separating the communications, user, and algorithmic portions of your code (a short list, especially if you are doing real-time systems) into their own threads, you increase the modularity and understandability of the code, you decrease the likelihood of introducing bugs due to unforeseen consequences, and you gain control over execution priority and synchronization.
A recent application that I worked on used threads for date-time management, communications, GUI, periodic remote requests, motion control, and watchdogs.
Of course, multithreading does come with its own issues, especially race conditions and things happening out of expected sequence, but these are manageable with semaphore, mutexes, and the like.
Reasons I can think of off the top of my head ( and I'm sure there are more ) are :
1. Offloading a batch of work to a worker thread so your program can either continue responding to user input or so you can carry on running other code that doesn't rely on that work.
2. Handling I/O particularly server and network communication where the response time is variable or unknown.
3. Parallel processing of data where you can sub-divide the work down into discrete non-dependant units of work
4. Timer related work i.e 'every 500ms check if x has changed'
However, switching to multi-threaded or concurrent programming is not without it's pitfalls particularly if those threads need to access shared data hence the number of questions on SO about mutexes and thread synchronisation!