Thursday, February 7, 2013

Theory of Computing Part 3a: The Operating System

To quote the wikipedia article, an operating system is "a collection of software that manages the computer hardware and provides common services for computer programs." This collection has evolved much more slowly than the programming tools mentioned earlier. This is primarily because early computers were limited to one program at a time and were much more hardware dependent, so there wasn't as much to manage.

Another article, on the history of operating systems covers this evolution in depth. What I will be covering in this post is more about the operating system's role in mediating between the hardware, the user, and the computer program. This will include an explanation of process management, programmer APIs, and a look at how the OS mediates the user interaction with the programs running on the computer. Unfortunately, it is hard to do this without a sizable amount of jargon so this entry will be more technical than some of the other entries.

The role of the OS

Up until now, the mental picture of how a computer does what it does is fairly straightforward. The processor reads a program as binary signals from memory, and executes the instructions it is given. There are still plenty of embedded systems or multi-controllers that work pretty much exactly that way. However, as the hardware has grown more complex, this picture has evolved into something different.

Instead of having the computer run each program one at a time on a blank slate, the computer runs a root program, called the kernel when it first starts up. The kernel manages which programs are allowed to run, how much access they have to the processor, how much memory they are allowed, what other devices or resources they have access to, etc.

Process Management

On a modern computer system, when your computer program runs, it is not given complete control over everything that is happening on the computer. Rather it is expected to follow a set of rules and is only allowed some of the processor time, and the kernel acts as the traffic cop, pushing programs into the processor queue when their supposed to and killing any process that doesn't obey the rules.

One good example of this is memory management. As mentioned before, when running a program, the processor loads each instruction from memory, executes that instruction, and then goes to the next instruction in memory and executes it, continuing until aborted.

As far as the program is concerned, the memory space is completely sequential and limited only by the address system of the computer. This is quite different from what happens under the surface as the kernel only allows the program to have a certain amount of memory address space, and if it tries to access memory outside of this space, the program is killed. Moreover, while the program uses addresses sequentially starting at 0, the actual hardware memory addresses are often mapped into a random system for security reasons, and the memory is converted from the program's internal memory address system, to the physical memory address by the kernel.

This same sort of management happens with processing time as well. While your program may act like it has completely control over the processor and is constantly being accessed, the kernel itself has final say over how many instructions get executed and it periodically sends its own instructions, or that of background processes through the processor while your program is running. If your program fails to relinquish control after a certain period of time, the kernel will kill the process.

In summary, the kernel in an OS is yet another example of a layer of abstraction in computing. When convenient, programmers can write their code pretending that it is the only thing being ran on the computer and it doesn't need to share resources or deal with memory issues. And the code will work just fine because the kernel takes of the nuts and bolts of actually interacting with the processor and any other hardware. However, if the programmer needs to do something more complex, as you will see in the next post, that the operating system is waiting to help.