Multithreading with the .NET Framework
- Thread Basics
- The Downside
- Implementing Multithreading
- A Demonstration
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Thread Basics
When your computer appears to be doing multiple things at once, what is really happening is that the CPU's time is being divided up between the various tasks. Task 1 — printing, for example — gets the CPU for some fraction of a second, then task 2, task 3, and so on. Because the computer is very fast and human perceptions are relatively slow it seems as if the tasks are being done simultaneously. This ability to share the CPU among multiple tasks is called multitasking, and it is a feature of the Windows operating system (and most other operating systems too).
The thread is the basic unit of multitasking, the entity to which the operating system assigns CPU time. Each program typically has a single thread, as do various background processes associated with the operating system. The operating system assigns CPU time to the running threads based on their priority. In Windows, a thread can have one of four priorities as described here from highest to lowest:
- Real time: used for processes that cannot be interrupted, such as games with complex graphics and streaming video.
- High: used for time-critical processes that must execute essentially immediately for proper function. The Windows Task manager is an example.
- Normal: used for processes that have no special CPU scheduling demands. Most application programs, such as a word processor or spreadsheet, are assigned this priority.
- Idle: used for processes that should run only when no higher priority process is active, in other words when the system is idle.
How does threading relate to the .Net programmer? A .Net program by default has a single thread, but you can create two or more threads within a single program if you desire. Because these threads are all part of the same program, or process, they all have access to the program's resources (global, static, and instance fields, for example). But because Windows allocates CPU time based on threads, not processes, a multithreaded program will get more than its normal share of CPU time.
What exactly does this mean in practical terms — does the program run faster? Generally speaking, no, at least on single processor computers. (Multiple processor systems are another story and beyond the scope of this article). It means, rather, that the program (or some programs, anyway) can be more responsive to the user. When a program has only a single thread, that thread is responsible for all program operations, including responding to user input, such as typing text into a text box, selecting menu commands, and clicking buttons. If the thread is occupied with long-running data processing, such as mathematical calculations or XSLT processing, response to the user can become sluggish. Click a menu title, for example, and it may take several seconds for the menu to appear. This can be very frustrating to the user, and a competent programmer will see that it never happens. By creating a second thread and assigning the long-running process to it, the programs initial, default thread can respond immediately to user input.