Multitasking Basics

Multitasking is the ability of a computer program to perform ”or seem to perform ”more than one task at a time. While multitasking can take many forms, cooperative multitasking (CM) and preemptive multitasking (PM) are two distinct models commonly used today. Most systems are moving toward the preemptive multitasking model.

Just as the assumptions about stand-alone applications were invalidated by LAN support requirements, multitasking invalidates programs that make assumptions about local resources. The issues involved are not terribly dissimilar: stand-alone applications were designed as if no other competing computers existed, and programs today often presume a static path of operations in which resources global to the program can still be used without concern for contention .

Cooperative Multitasking

The first multitasking model is cooperative multitasking; CM was used in Microsoft Windows prior to Windows NT and Windows  95. The use of CM implied a certain model of Windows programming that is still employed, though often hidden beneath an application framework (Microsoft Visual  C++ and Microsoft Foundation Classes) or a visual programming model (Microsoft Visual Basic or Borland Delphi).

As the name implies, CM requires the cooperation of the programs involved. However, more than mere resource sharing, cooperation enables a program to take an active part in making the system available to other programs. At the heart of any Windows 3.x program is a message pump routine that resembles the following:

 while(GetMessage(&msg,NULL,0,0)) { TranslateMessage(&msg); DispatchMessage(&msg); } 

All three function calls are Windows API functions ”not your own. How does your code run? DispatchMessage calls a window procedure that you have written if the message received is destined for the window associated with that message procedure.

However, the call to GetMessage does more than simply get the next message for your program to process. It also returns control to Windows, which allows other programs to run if no messages are available for your program or if the messages waiting are low priority (such as requests to paint the screen or timer notifications). Periodically calling GetMessage is more than a requirement for your program to get its next message; it is critical to the correct functioning of the entire Windows system. Note that Windows 3.x device drivers do gain control without calling GetMessage , PeekMessage , or WaitMessage .

The CM model requires the cooperation of every program in the system. Each program can behave as if it is the only program running between calls to GetMessage or between calls to another function that yields control to Windows. Of course, it is possible that you will discover one program that will not work and play well with others. This is the problem with the CM model.

If you have used Windows 3.x for any period of time, you have seen the symptoms of this problem. You initiate a task, the hourglass cursor appears, and you wait. You wait for an awfully long time. Hardware interrupts are not disabled because your mouse moves and the Num Lock light toggles when you press the Num Lock key. The machine seems to be doing something, but the task never seems to complete. You have discovered the chink in cooperative multitasking armor : CM requires cooperation, and sometimes we write programs that refuse to cooperate. When this situation occurs in Windows 3.0, the machine always requires a reboot. In Windows  3.1 and later, you have one last chance to recover by pressing Ctrl-Alt-Delete; if the system is suffering because of a program that is not relinquishing control, you are given a chance to close the offending application and continue. Of course, all your unsaved work is lost.

Understanding why Windows 3.x used this model requires an understanding of the hardware limitations that existed when Windows was first envisioned . The first version of Windows to receive widespread use was Windows 386, which became available shortly before Windows 3.0. The determining factor that made the CM model attractive was the necessity of running Windows on both a 386 and a 286. CM allowed multiple programs to work with very little overhead imposed by the multitasking model.

Other popular systems have used CM for the same reasons. NetWare uses a CM model, though the model is implemented in such a way that it imposes less structure on programs written for that platform. Dozens of NetWare function calls can yield control to the operating system. This requires that NetWare NLM programmers know which calls can yield control so they can ensure that any necessary events take place without operating system intervention.

Preemptive Multitasking

CM is sometimes called nonpreemptive multitasking to contrast it with the other major model: preemptive multitasking. PM seems much simpler on the surface, but its implementation is often more complex at the operating system level and can create unforeseen problems for the application programmer.

The basic premise of PM is that a scheduler at the operating system level controls how long each process is allowed to operate. The amount of time is often called a time slice. After the time slice is up, another program is allowed to function and the original program waits for the scheduler to allow it to operate again. This seems like a more reasonable model of operation than the CM model. Problems, however, await the unaware.

Imagine you have two operations: one in a function dothis and the other in a function dothat. Consider the following code:

 dothis(); dothat(); 

You cannot be sure that these operations will be performed in their entirety without other processes taking control. If dothis operates on some globally available resource (for instance, a file or a device), you cannot be assured that dothat will get to the resource before some other process operates on it. This is a major departure from the model that presumes the program operating is in total control of the machine.