Categories: Operating Systems

Continued from Introduction

In Windows 3.x, each instance of a running application program constitutes one task. The operating system divides the CPU among tasks, using a cooperative scheduling mechanism that relies on each application to yield processing time to others. Scheduling is performed on a per-task basis, so switching from one task to another basically means that Windows saves the CPU registers for the task that is losing activation and restores the register values last saved for the task being switched to. It then begins executing code where that task left off.

In the Win32 environment, we no longer think of programs in terms of tasks, but rather in terms of processes and threads. A process is one instance of a running application and all the memory and other resources associated with it. A thread is one path of execution through the application's code. A process can consist of one thread or it can consist of many. Processes and threads are preemptively multitasked, so it's no longer necessary for one application to yield so that others can get processing time. Instead, the operating system uses a sophisticated scheduling mechanism to forcibly interrupt, or preempt, the currently active thread when it's time for another to get a turn. This produces a smoother form of multitasking that distributes time more fairly among applications and makes all applications more responsive to input when several are running at once. Responsiveness is important, because a sluggish mouse or keyboard is the first thing a user will notice if an application doesn't perform up to standards.

To put the difference in perspective, think of each task in 16-bit Windows as a single thread of execution. The program is executed in a linear fashion, from top to bottom, following the path represented by the thread. In 32-bit Windows, a process starts life as a single thread, but it can spawn additional threads to perform background tasks such as formatting a disk or recalculating a spreadsheet. Each thread is like a fork in the road describing a path for the CPU to follow, and each path is executed (and multitasked) independently, as if it were a separate program.

By splitting CPU time among concurrent threads, Windows 95 and OS/2 create the illusion that the threads run in parallel. On a machine with multiple CPUs, Windows NT really does run two or more threads at the same time by assigning different threads to different processors. This feature is known as symmetric multiprocessing, or SMP. PCs with two or more CPUs are novelties today, but in a few short years we'll all be running 4 to 16 processors in a box. And when we do, we'll all want SMP.

In Windows 95, as in Windows NT and OS/2, it is the thread, and not the process or task, that is the atomic unit of execution. If an application wants to do several things at once, it can simply dedicate a thread to each. The operating system then makes sure that each thread gets the CPU time it requires. A 16-bit application, by contrast, can carry out two operations at once only if it contains special--and usually very tricky--code to alternate between them. This usually means that each operation must be subdivided into smaller pieces that can be performed alternately. It also means that if one piece of one operation takes longer than it should to execute, the other half of the program loses out on needed processor time. If the half that gets shortchanged is the one that reads and processes input from the user, the application will suddenly seem sluggish and unresponsive.

The diagram in Figure 1 illustrates the difference between single and multiple threads of execution in two hypothetical word processing programs. At one point in each program, the user selects Print from the File menu and the application begins sending the document to the printer. Printing is done in the background, so the user can continue typing.

First, consider the single-threaded application on the left. When printing is begun, the application begins alternately checking for input and sending data to the printer. The program logic is complicated because the printing process must be broken into steps and performed one step at a time. Worse, the application's responsiveness suffers, because mouse and keyboard events are accorded no priority over the printing process. If the user presses a key right after the application begins printing a block of data, the event languishes in an input queue until the application turns its attention away from the printer. Input latencies can be reduced by breaking the printing process into smaller pieces requiring less time to execute, but that, too, has its drawbacks: More time devoted to checking for input means more time needed for printing.

In the multithreaded application, background printing is no big deal; the program starts a second thread, whose sole purpose is to output the document to the printer. While that thread is running, the operating system switches rapidly between the input thread and the print thread so that both appear to be running at once. Moreover, each thread is utilized with maximum efficiency. While the input thread awaits input, the print thread receives the lion's share of the CPU. But as soon as the user presses a key or clicks a mouse button, the print thread is preempted and control is transferred back to the input thread. No time is wasted waiting for input, but when an input event occurs, the program responds immediately.

Ever notice how difficult it is to do meaningful work while the Windows 3.1 Print Manager prints a large document? Now you know why: Print Manager isn't able to do its printing in a separate thread. Instead, it has to print a few characters, yield, print a few more characters, yield, and keep repeating this process until printing is completed. Typed characters and other input wait in line for processing behind chunks of data transmitted to the printer. In Windows 95, Windows NT, and OS/2, however, background printing is demonstrably less intrusive, in part because print spooling is performed by a dedicated thread that is preempted by input events. This is clear evidence of the difference that multithreading can make.

Continues...

Published as Tutor in the 12/05/95 issue of PC Magazine.