The majority of operating systems provide certain essential concepts and abstractions such as processes, address spaces, and files that are most important to understanding them. In the following sections, we will look at some of these main concepts ever so briefly, as an introduction. We will come back to each of them in great detail later in this blog. To illustrate these concepts we will use examples from time to time, usually drawn from UNIX. Alike examples generally exist in other systems as well, however, and we will study Windows Vista in detail in "CASE STUDY 2: WINDOWS VISTA".


A main concept in all operating systems is the process. A process is basically a program in execution. Associated with each process is its address space, a list of memory locations from 0 to some maximum, which the process can read and write. The address space contains the executable program, the program's data, and its stack. Also linked with each process is a set of resources, usually including registers (including the program counter and stack pointer), a list of open files, outstanding alarms, lists of related processes, and all the other information required to run the program. A process is basically a container that holds all the information required to run a program.

We will come back to the process concept in much more detail in "PROCESSES AND THREADS", but for now, the easiest way to get a good instinctive feel for a process is to think about a multiprogramming system. The user may have a started a video editing program and instructed it to convert a one-hour video to a certain format (something that can take hours) and then gone off to surf the Web. In the meantime, a background process that wakes up from time to time to check for incoming e-mail may have started running. Therefore we have (at least) three active processes: the video editor, the Web browser, and the e-mail receiver. Periodically, the operating system decides to stop running one process and start running another; for instance, because the first one has used up more than its share of CPU time in the past second or two.

When a process is suspended for the time being like this, it must later be restarted in exactly the same state it had when it was stopped. This means that all information about the process must be explicitly saved somewhere during the suspension. For instance, the process may have a number of files open for reading at once. Attached with each of these files is a pointer giving the current position (i.e., the number of the byte or record to be read next). When a process is for the time being suspended, all these pointers must be saved so that a read call executed after the process is restarted will read the appropriate data. In many operating systems, all the information about each process, other than the contents of its own address space, is stored in an operating system table called the process table, which is an array (or linked list) of structures, one for each process currently in  existence.

Hence, a (suspended) process contains its address space, generally called the core image (in honor of the magnetic core memories used in days of yore), and its process table entry, which includes the contents of its registers and many other items required to restart the process later.

The key process management system calls are those dealing with the creation and termination of processes. Consider a typical example. A process called the command interpreter or shell reads commands from a terminal. The user has just typed a command requesting that a program be compiled. The shell must now create a new process that will run the compiler. When that process has finished the compilation, it executes a system call to terminate itself.

If a process can create one or more other processes (referred to as child processes) and these processes in turn can produce child processes, we quickly arrive at the process tree structure of the following figure.Related processes that are cooperating to get some job done frequently need to communicate with one another and synchronize their activities. This communication is called interprocess communication, and will be addressed in detail in "PROCESSES AND THREADS".

A process tree. Process

Other process system calls are available to request more memory (or release unused memory), wait for a child process to come to an end, and overlay its program with a different one.

Infrequently, there is a need to convey information to a running process that is not sitting around waiting for this information. For instance, a process that is communicating with another process on a different computer does so by sending messages to the remote process over a computer network. To guard against the possibility that a message or its reply is lost, the sender may request that its own operating system notify it after a specified number of seconds, so that it can retransmit the message if no acknowledgement has been received yet. After setting this timer, the program may continue doing other work.

When the specified number of seconds has elapsed, the operating system sends an alarm signal to the process. The signal causes the process to temporarily suspend whatever it was doing, save its registers on the stack, and start running a special signal handling procedure, for example, to retransmit a presumably lost message. When the signal handler is done, the running process is restarted in the state it was in just before the signal. Signals are the software analog of hardware interrupts and can be generated by a variety of causes in addition to timers expiring. Many traps detected by hardware, such as executing an illegal instruction or using an invalid address, are also converted into signals to the guilty process.

Each person authorized to use a system is assigned a UID (User IDentification) by the system administrator. Every process started has the UID of the person who started it. A child process has the same UID as its parent. Users can be members of groups, each of which has a GID (Group IDentification).

One UID, called the superuser (in UNIX), has special power and may violate many of the protection rules. In large installations, only the system administrator knows the password needed to become superuser, but many of the common users (especially students) devote considerable effort to trying to find flaws in the system that allow them to become superuser without the password.

We will study processes, interprocess communication, and related issues in "PROCESSES AND THREADS".


process, multiprogramming, alarm signal