Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A Motivation for Thread Creation
Suppose you create a simple application that has a fairly conversational style of GUI—the user makes a request and the application can respond instantly. In other words, your program doesn’t do a whole lot of background processing. You can get away with a single-threaded approach in this case for a while.
However, at a later date you decide to add a substantial block of standalone processing. The processing in question might be code that downloads a large file from a remote server. The problem is that during the download, your GUI is locked and unresponsive. Worse still, the user may not be able to cancel a download if he changes his mind. This is a typical scenario that might motivate the implementation of thread logic. You can elect to put the download code into a separate thread of execution. This in turn allows the user to abort a download if required. (You’ve got to keep those demanding users happy!)
In this simple case, a multithreaded application becomes more responsive to the user. This approach improves the user experience of your code and makes your program look more professional. Multithreaded programming is full of pitfalls, but if you follow some simple rules and walk before you run, you should be okay!
Let’s look at a more serious multithreaded problem: controlling software downloads in a complex network.