Information Technology Reference
In-Depth Information
As we will se, the operating system kernel can often have many different
concurrent activities, each with its own execution stack. Because we need to
grow these stacks dynamically, many kernels also use virtual addresses for at
least some of their data.
Here is a simple test to verify that your computer supports virtual addresses.
Suppose we write a program with a static variable and a procedure local variable
allocated on the stack. The program updates the value of each variable, waits
for a bit, and then prints the locations of the variables and their values.
If we start multiple copies of this program running simultaneously on a
modern operating system with virtual addressing, each prints exactly the same
result. That would be impossible if the programs were directly addressing phys-
ical memory locations. In other words, each instance of the program appears
to have its own complete copy of memory, so that when it stores a value to a
memory location, it is the only one that sees its changes to that location. Other
processes change their own copy of the memory location. This way, a process
cannot alter any other process's memory, because it has no way of referencing
the other process's memory. Instead, only the kernel can read or write the
memory of a process other than itself.
This is very much akin to a set of television shows, each occupying their own
universe, even though they all appear on the same television. Events in one
show do not (normally) affect the plot lines of other shows. Sitcom characters
are blissfully unaware that Jack Bauer has just saved the world from nuclear
Armageddon. Of course, just as television shows can from time to time share
characters, processes can also communicate if the kernel allows it.
We will
discuss how this happens in a later chapter.
2.2.2
Timer interrupts
Process isolation also requires that the hardware provide a way for the oper-
ating system kernel to periodically regain control of the processor. When the
operating system starts a user-level program, the process is free to execute any
user-level (non-privileged) instructions it chooses, call any function in the pro-
cess's memory region, load or store any value to its memory, and so forth. To
the user program, it appears to have complete control of the hardware, within
the limits of its memory region.
However, this too is only an illusion. If the application enters an infinite
loop, or if the user simply becomes impatient and wants the system to stop the
application, then the operating system needs to be able to regain control. Of
course, the operating system needs to be able to execute instructions to be able
to decide if it should stop the application, but if the application controls the
processor, the operating system by definition is not running. A similar issue
occurs in more normal circumstances. Suppose you are listening to music on
your computer, downloading a file, and typing at the same time.
To be able
