What Is Multi-Threading?

In simple terms, multi-threading is the ability to run different pieces of code (methods) seemingly at the same time. One can imagine multi-threading like multi-tasking within a single application.

Of course, computers generally cannot do multiple things at the same time (unless you're talking about a multi-processor system). Instead, different tasks and threads have to share processing resources and the operating system assigns "time slices" to different tasks and threads in a round-robin fashion.

You can use multi-threading for a variety of scenarios. A simple example is Internet Explorer: Whenever one uses IE to navigate to a Web site, the download engine is busy retrieving information from the web site. However, while information downloads, the user interface is "alive" and ready to be used. The user can move the window around, resize it, and if parts of the page have already been downloaded they can scroll up and down in the part of the page that has already been rendered. The reason one can use the interface while downloading and rendering is still in progress is that all these things run on separate threads. Presumably there is a thread for the interface, a thread for downloading information, and a rendering thread (and perhaps others that are not as obvious). If all these things were done on the same thread, the user would have to wait for a page to download completely and then render before they could browse to a different site or even close the window.

Another multi-threading example is the background spell checker that serves me quite well while I am typing text into MS Word. As I type, Word silently checks my spelling and highlights spelling mistakes as I go. This feature does not interrupt my typing no matter how quickly I type. Spell checking happens on a separate thread (probably on a background thread�a thread of lower priority�ensuring that it will not take away too much processing time from the main application thread).

Most readers are not about to implement their own Web browsers or text processing applications, but how about an auto-complete textbox that finds matching values in a database while the user types? (You can see similar behavior in Internet Explorer when you enter a URL in the address bar.) You wouldn't want to interrupt the user while they're typing, so a task like this is best performed using a separate thread.

Or how about background verification of data entry forms? Instead of verifying entries when the user tabs out of a textbox (or other control), which is very interruptive if the logic is complex and perhaps data intensive, this could be done on a background task using a lower priority thread.

Threads do not improve performance. They make a system more responsive by creating the illusion of performing multiple tasks at once rather than putting one process on hold while it performs another. All threads taken together have the same processing power as before (unless the application runs on a multi-processor machine, which can truly execute two things at the same time). The system must use some of the available processing time for the thread switching operations making total performance worse than before. Don't underestimate this overhead! In fact, if you spin up a lot of threads, switching between the threads may take up more time than running the threads.

Threading and Windows Forms

One of the issues that surprises most developers is that .NET Windows Forms are not thread-safe. It is not safe to call a method on a Windows form or control from a secondary thread. Although this may seem strange at first, as a developer you actually want this. Thread-safety doesn't come for free! If Windows Forms were programmed in a thread-safe way, all single threaded applications would pay a hefty performance penalty.

Does that mean Windows Forms applications cannot be used in a multi-threaded environment? No! It simply means that the architect of a multi-threaded Windows Forms application has to worry about thread-safety himself.