Categories: Operating Systems

Continued from Uses for Multiple Threads

Of course, theory can only take you so far. Ultimately, it's instructive to see a hands-on demonstration of the difference that multithreading can make. For this reason, I've written a pair of Windows 95 programs named Threads1 and Threads2 that you can download from PC Magazine Online. Both programs do exactly the same thing, but Threads1 uses one thread of execution to get the job done, while Threads2 uses up to three. The difference between the two programs is hardly earthshaking (Threads1 uses plenty of tricks to make it seem like there's more than one thread running), but it is illustrative nonetheless.

For starters, open Threads2 (shown in Figure 3) and select Start Clock from the Options menu. This launches a second thread that spins the clock hands continuously. Now decrease the window size, tuck it away in one corner of the screen, and start an application such as Excel or Word. Notice that the clock hands spin just about as fast when Threads2 is running in the background as when it's running in the foreground. Also notice that typing a character in Word or Excel momentarily slows the spinning hands. That's a result of the dynamic priority boosting that the system does in response to input messages. Word or Excel's input thread gets a temporary boost when a key is pressed, which takes a few CPU cycles away from the thread that spins the hands. After 2 or 3 seconds, the input thread resumes its normal priority and the hands speed up again.

Now, with the clock still running, select Start Disk Check from the Options menu. This starts a third thread that examines every directory on the C: drive and, when it's finished, displays a count of files and directories. The check usually takes several seconds, and during that time the hands slow to roughly half their normal speed. The CPU can't do two things at once, so when it executes two threads of equal priority and neither thread is a user-interface thread (meaning neither thread checks the message queue and therefore can't become suspended while waiting for user input), each thread performs at about half its normal pace. But even with two relatively time-consuming background operations going on, Threads2 continues to respond ably to user input. Menus pop up quickly, and there is no perceptible delay when you type characters in the edit control at the bottom of the window.

Threads1 attempts to do the same thing with only one thread. But notice that when you pull down a menu, the hands stop. They also stop when a message box is displayed, and they remain frozen for the entire time that a disk check is in progress. Some clever coding could partially mitigate these deficiencies, but take my word for it that Threads1 already has its share of clever coding just to make the hands spin and the disk check work without severely compromising responsiveness. The edit control at the bottom of the window works pretty well, but there is a small amount of jerkiness evident when typing while a disk check is performed.

There are other experiments you can try, too. For example, line up four copies of Threads2 in a row and watch the hands as you switch among applications. The speed of the hands is roughly indicative of the number of time slices each thread is getting, because the clock thread tries to move the hands as quickly as it can. Repeat the experiment with Threads1 and you'll find that multitasking is noticeably less smooth, as evidenced by the more irregular movement of the hands.

Continues...

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