A thread is an independent unit of execution within a process. The multithreaded programming challenge requires organization and coordination of thread execution to simplify programs and to take advantage of the inherent parallelism of the host computer.
Traditionally, programs execute as a single thread of execution. While several processes can execute concurrently, as in the Chapter 6 examples, and even interact through mechanisms such as shared memory or pipes (Chapter 11), single-threaded processes have several disadvantages.
It is expensive and time consuming for the OS to switch running processes, and, in cases such as the multiprocess search (grepMP, Program 6-1), the processes are all executing the same program. Threads allow concurrent file processing within a single process, reducing overall system overhead.
Except in the case of shared memory, processes are not tightly coupled to one another, and it is difficult to share resources, such as open files.
It is difficult and inefficient for single-threaded processes to manage several concurrent and interacting tasks, such as waiting for and processing user input, waiting for file or network input, and performing computation.
I/O-bound programs, such as the ASCII to Unicode conversion program in Chapter 2 (atou, Program 2-4) are confined to a simple read-modify-write model. When you're processing sequential files, it can be more efficient to initiate as many read operations as possible. Windows NT also allows asynchronous overlapped I/O (Chapter 14), but threads can achieve the same effect with less programming effort.
The Windows executive will schedule independent threads on separate processors of an SMP system, frequently improving performance.
This chapter discusses Windows threads and how to manage them. The examples illustrate thread usage with parallel file searching and a multithreaded sort. These two examples contrast I/O- and compute-intensive concurrent activities performed with threads. This chapter also presents an overview of Windows process and thread scheduling.
This chapter and those that follow take the point of view that not only do threads make certain programs simpler to design and implement but, with attention to a few basic rules and programming models, threaded programs also can improve performance and be reliable, easy to understand, and maintainable. Thread management functions are very similar to the process management functions so that, as just one example, there is a GetThreadExitCode function that is comparable to GetProcessExitCode.
This point of view is not universally accepted. Many writers and software developers mention thread risks and issues and prefer to use multiple processes when concurrency is required. Issues and concerns include the following.
Threads share storage and other resources within a process, so one thread can accidentally modify another thread's data.
In certain circumstances, concurrency can drastically degrade, rather than improve, performance.
Threads share storage and other resources within a process, and this can lead to defects such as race conditions and deadlocks.
Some of the issues are real but can be avoided with careful design and programming, and many of the issues are inherent to concurrency, whether using threads within a process, multiple processes, or special-purpose techniques, such as Windows asynchronous I/O.