When to Create a Thread

[Previous] [Next]

A thread describes a path of execution within a process. Every time a process is initialized, the system creates a primary thread. This thread begins executing with the C/C++ run-time library's startup code, which in turn calls your entry-point function (main, wmain, WinMain, or wWinMain) and continues executing until the entry-point function returns and the C/C++ run-time library's startup code calls ExitProcess. For many applications, this primary thread is the only thread the application requires. However, processes can create additional threads to help them do their work.

Every computer has an extremely powerful resource: the CPU. There is absolutely no reason in the world why the CPU should be idle (if you ignore power conservation issues). To keep the CPU busy, you give it varied tasks to perform. Here are a few examples:

• You can turn on the content indexing service that ships with Microsoft Windows 2000. It creates a low-priority thread that periodically wakes up and indexes the contents of the files on your disk drives. To locate a file, you invoke the Search Results window (by clicking the Start button, then selecting For Files Or Folders from the Search menu) and enter your search criteria in the Containing Text field. The index is searched and the relevant files are immediately displayed. The content indexing service improves performance greatly because each search doesn't have to open, scan, and close every file on your disk drives.
• You can use the disk defragmenting software that ships with Windows 2000. Normally, this type of utility has many administrative options that the average user can't understand, such as how often the utility should run and when. Using lower-priority threads, you can run the utility in the background and defragment the drive when the system is otherwise idle.
• You can easily imagine a future version of the compiler that automatically compiles your source code file whenever you pause typing. The output window would show you warnings and errors in (almost) real time. You would see immediately when you mistyped a variable or function name. To some extent, Microsoft Visual Studio does this already; you can see it using the Workspace's ClassView pane.
• Spreadsheet applications can perform recalculations in the background.
• Word processors can perform repagination, spelling and grammar checking, and printing in the background.
• Files can be copied to other media in the background.
• Web browsers can communicate with their servers in the background. A user can thus resize the browser's window or go to another Web site before the results from the current Web site have come in.

One important thing that you should notice about many of these examples is that multithreading allows the application's user interface to be simplified. If the compiler builds your application whenever you stop typing, there is no need to offer a Build menu option. The word processor application doesn't need Check Spelling and Check Grammar menu options.

In the Web browser example, notice that using a separate thread for I/O (be it network, file, or other) allows the application's user interface to stay responsive. You can imagine an application that sorts the records of a database, prints a document, or copies files. By using a separate thread for this I/O-bound task, a user can continue to use your application's interface to cancel the operation while in progress.

Designing an application to be multithreaded allows that application to scale. As we'll see in the next chapter, each thread is assigned a CPU. So if you have two CPUs in your computer and two threads in your application, both CPUs will be busy. In effect, you get two tasks done in the time it would take for one.

Every process has at least one thread in it. So if you do nothing special in your application, you already get a lot of benefit just from running on a multithreaded operating system. For example, you can build an application and use the word processor at the same time (something I do a lot). If the computer has two CPUs, the build executes on one processor while the other processor handles a document. In other words, the user notices no degradation in performance. Also, if the compiler has a bug that causes its thread to enter an infinite loop, you can still use other processes. (This is not true of 16-bit Windows and MS-DOS applications.)