This is a message that I posted to the CompuServe Mensa Forum in February 2000, in response to a poster who didn’t seem to understand how operating systems were able to handle endless loops.
>> A good OS copes with endless
looping, be it with 1, 2 or n processors. <<
> This is not true. The OS has no way of recognizing repetitive
loops, and so it cannot allow for them.
If an application asks for processor time, the OS must supply it. Every OS slows when processor time is
exhausted, and so a single application that demands nothing but processor time
will slow the entire system. <
Let me jump in, folks, and explain
how Operating Systems can allow for repetitive loops, without needing to
recognize them. (You can trust me! I'm a Mensan with a Masters Degree in
Computer Science! <G>) And although my work has been in areas other
than Windows programming, so that I don't have all the latest details on
exactly how Windows 95 and Windows 98 work, I think I can help this discussion
along.
First, let me present and illustrate
some concepts. All operating systems
that are capable of running more than one application at a time have a central
routine in the operating system called a "scheduler". The scheduler decides, usually several times
per second, when to allocate the computer's CPU to one application so that the
application can run, and when to temporarily stop that application and instead
run another application for a while.
(Actually, the scheduler usually allocates the CPU to parts of an entire
application; these parts can be called tasks or threads. But for simplicity we'll just talk about
applications.) You can see this
scheduler in operation if you have print spooling enabled (Windows usually
does) and you tell your computer to print a web page while you're running a
browser such as Netscape or Internet Explorer.
The browser does the work of translating the web page into codes that
the printer will understand, writes those codes to your hard drive, and then
tells the print spooler (which is an application in its own right) that the
codes are there to be printed. The
print spooler then begins printing those codes, while you are free to continue
browsing other web pages. Both the
browser and the print spooler appear to be running at the same time, but in
reality the computer's CPU can only run one at a time. The scheduler in Windows switches the CPU
from the browser to the print spooler and back several times a second to give
the impression that they are both running at the same time.
If you had more than one CPU in a
computer system, an operating system that was aware of this could choose to
keep two applications at a time running simultaneously, without having to stop
one in order to start the other. I'm
not sure on the specifics, but I believe that Windows 95, 98 don't know how to
use more than one CPU, but that WIndows NT 3.51, 4.0, and Windows 2000 -do-.
To keep the discussion simple, we'll
continue to talk about systems with just one CPU. Now, let's talk about those repetitive loops. We've said that the scheduler switches the
CPU from one application to another several times a second. But the scheduler inside the operating
system is a program, just like the applications. The scheduler can't run when the CPU is running an application;
somehow the CPU has to leave that application and go run the scheduler. The way in which this "leaving" is
done is the heart of the matter.
Windows 3.1 (and I believe, Windows 95, and 98) operating systems all
need any running Windows applications to voluntarily execute, usually several
times a second, a routine in the Windows application that causes the
application to pause and let the scheduler run. The scheduler will then decide either to continue running that
same application, or to run a different application. If it picks a different Windows application, that application is
likewise expected to voluntarily execute a routine to pause and let the
scheduler run, so that eventually the first Windows applications gets to run
again. The fancy name for this is
"cooperative multitasking"; the different tasks have to cooperate in
sharing the CPU.
If a Windows application has a large
repetitive loop, so that it takes a long time before calling the routine that
invokes the scheduler, that application can appear to take over the system for
a long time and keep other applications from running. (The application's not being very cooperative in this case, is
it? <G>)
Some time ago, computer scientists
decided that this was not a good thing to have happen, because some
applications might need to be continuously quickly responding to events that
are taking place in the real world.
(Such as an application controlling the heat and fluid flow in an oil
refinery, or a nuclear power plant.) So
the concept of "preemptive multitasking" was developed. Under preemptive multitasking, applications
don't have to voluntarily let the scheduler run; instead, their execution is
"preempted", or interrupted, wherever it might be in its code, and
the CPU begins running the scheduler instead.
The computer system hardware makes this happen by using a mechanism
called a "hardware interrupt" that automatically and repetitively
happens several times a second. When
the scheduler decides to resume running the preempted application, it remembers
exactly where in the code that application was interrupted, and resumes it from
that point. The application program
continues running as if no interrupt had ever occurred.
I believe (but somebody check me on
this) that Unix, Windows NT 3.51, NT 4.0, and Windows 2000 all implement
"preemptive multitasking" to some degree, so that they can switch
quickly between applications that have repetitive loops.
Somebody want to take it from here?
Wayne Farmer