One basic concept of an operating system is the process. If we think of the program as the file stored on the hard disk or floppy and the process as that program in memory, we can better understand the difference between a program and a process. Although these two terms are often interchanged or even misused in “casual” conversation, the difference is very important for issues that we talk about later. Often one refers to an instance of that command or program.
A process is more than just a program. Especially in a multi-user, multi-tasking operating system such as UNIX, there is much more to consider. Each program has a set of data that it uses to do what it needs. Often, this data is not part of the program. For example, if you are using a text editor, the file you are editing is not part of the program on disk, but is part of the process in memory. If someone else were to be using the same editor, both of you would be using the same program. However, each of you would have a different process in memory. See the figure below to see how this looks graphically.
Image – Reading programs from the hard disk to create processes. (interactive)
Under UNIX, many different users can be on the system at the same time. In other words, they have processes that are in memory all at the same time. The system needs to keep track of what user is running what process, which terminal the process is running on, and what other resources the process has (such as open files). All of this is part of the process.
With the exception of the init process (PID 1) every process is the child of another process. In general, every process has the potential to be the parent of another process. Perhaps the program is coded in such a way that it will never start another process. However, this is a limitation of that programm and not the operating system.
When you log onto a UNIX system, you usually get access to a command line interpreter, or shell. This takes your input and runs programs for you. If you are familiar with DOS, you already have used a command line interpreter: the COMMAND.COM program. Under DOS, your shell gives you the C:> prompt (or something similar). Under UNIX, the prompt is usually something like $, #, or %. This shell is a process and it belongs to you. That is, the in-memory (or in-core) copy of the shell program belongs to you.
If you were to start up an editor, your file would be loaded and you could edit your file. The interesting thing is that the shell has not gone away. It is still in memory. Unlike what operating systems like DOS do with some programs, the shell remains in memory. The editor is simply another process that belongs to you. Because it was started by the shell, the editor is considered a “child” process of the shell. The shell is the parent process of the editor. (A process has only one parent, but may have many children.)
As you continue to edit, you delete words, insert new lines, sort your text and write it out occasionally to the disk. During this time, the backup is continuing. Someone else on the system may be adding figures to a spreadsheet, while a fourth person may be inputting orders into a database. No one seems to notice that there are other people on the system. For them, it appears as though the processor is working for them alone.
Another example we see in the next figure. When you login,
you normally have a single process, which is your login shell
(bash). If you start the X
Windowing System, your shell starts another process, xinit. At this point, both your shell and
xinit are running, but the shell is waiting for xinit to complete. Once X starts, you may want a
terminal in which you can enter commands, so you start xterm.
Image – Relationship between parent and child processes. (interactive)
From the xterm, you might then start the ps command, to see what other processes are running. In addition, you might have something like I do, where a clock is automatically started when X starts. At this point, your process tree might look like the figure above.
The nice thing about UNIX is that while the administrator is backing up the system, you could be continuing to edit your file. This is because UNIX knows how to take advantage of the hardware to have more than one process in memory at a time. (Note: It is not a good idea to do a backup with people on the system as data may become inconsistent. This was only used as an illustration.)
As I write this sentence, the operating system needs to know whether the characters I press are part of the text or commands I want to pass to the editor. Each key that I press needs to be interpreted. Despite the fact that I can clip along at about thirty words per minute, the Central Processing Unit(CPU) is spending approximately 99 percent of its time doing nothing.
The reason for this is that for a computer, the time between successive keystrokes is an eternity. Let’s take my Intel Pentium running at a clock speed of 1.7 GHz as an example. The clock speed of 1.7 GHz means that there are 1.7 billion(!) clock cycles per second. Because the Pentium gets close to one instruction per clock cycle, this means that within one second, the CPU can get close to executing 1.7 billion instructions! No wonder it is spending most of its time idle. (Note: This is an oversimplification of what is going on.)
A single computer instruction doesn’t really do much. However, being able to do 1.7 billion little things in one second allows the CPU to give the user an impression of being the only one on the system. It is simply switching between the different processes so fast that no one is aware of it.
Each user, that is, each process, gets complete access to the CPU for an incredibly short period of time. This period of time (referred to as a time slice) is typically 1/100th of a second. That means that at the end of that 1/100th of a second, it’s someone else’s turn and the current process is forced to give up the CPU. (In reality, it is much more complicated than this. We’ll get into more details later.)
Compare this to an operating system like standard Windows (not Windows NT/2000). The program will hang onto the CPU until it decides to give it up. An ill-behaved program can hold onto the CPU forever. This is the cause of a system hanging because nothing, not even the operating system itself, can gain control of the CPU. Linux uses the concept of pre-emptive multi-tasking. Here, the system can pre-empt one process or another, to let another have a turn. Older versions of Windows, use co-operative multi-tasking. This means the process must be “cooperative” and give up control of the CPU.
Depending on the load of the system (how busy it is), a process may get several time slices per second. However, after it has run for its time slice, the operating system checks to see if some other process needs a turn. If so, that process gets to run for a time slice and then its someone else’s turn: maybe the first process, maybe a new one.
As your process is running, it will be given full use of the CPU for the entire 1/100th of a second unless one of three things happens. Your process may need to wait for some event. For example, the editor I am using to write this in is waiting for me to type in characters. I said that I type about 30 words per minute, so if we assume an average of six letters per word, that’s 180 characters per minute, or three characters per second. That means that on average, a character is pressed once every 1/3 of a second. Because a time slice is 1/100th of a second, more than 30 processes can have a turn on the CPU between each keystroke! Rather than tying everything up, the program waits until the next key is pressed. It puts itself to sleep until it is awoken by some external event, such as the press of a key. Compare this to a “busy loop” where the process keeps checking for a key being pressed.
When I want to write to the disk to save my file, it may appear that it happens instantaneously, but like the “complete-use-of-the-CPU myth,” this is only appearance. The system will gather requests to write to or read from the disk and do it in chunks. This is much more efficient than satisfying everyone’s request when they ask for it.
Gathering up requests and accessing the disk all at once has another advantage. Often, the data that was just written is needed again, for example, in a database application. If the system wrote everything to the disk immediately, you would have to perform another read to get back that same data. Instead, the system holds that data in a special buffer; in other words, it “caches” that data in the buffer. This is called the buffer cache.
If a file is being written to or read from, the system first checks the buffer cache. If on a read it finds what it’s looking for in the buffer cache, it has just saved itself a trip to the disk. Because the buffer cache is in memory, it is substantially faster to read from memory than from the disk. Writes are normally written to the buffer cache, which is then written out in larger chunks. If the data being written already exists in the buffer cache, it is overwritten. The flow of things might look like this:
Image – Different layers of file access. (interactive)
When your process is running and you make a request to read from the hard disk, you typically cannot do anything until you have completed the write to the disk. If you haven’t completed your time slice yet, it would be a waste not to let someone else have a turn. That’s exactly what the system does. If you decide you need access to some resource that the system cannot immediately give to you, you are “put to sleep” to wait. It is said that you are put to sleep waiting on an event, the event being the disk access. This is the second case in which you may not get your full time on the CPU.
The third way that you might not get your full time slice is also the result of an external event. If a device (such as a keyboard, the clock, hard disk, etc.) needs to communicate with the operating system, it signals this need through the use of an interrupt. When an interrupt is generated, the CPU itself will stop execution of the process and immediately start executing a routine in the operating system to handle interrupts. Once the operating system has satisfied this interrupt, it returns to its regularly scheduled process. (Note: Things are much more complicated than that. The “priority” of both the interrupt and process are factors here. We will go into more detail in the section on the CPU.)
As I mentioned earlier, there are certain things that the operating system keeps track of as a process is running. The information the operating system is keeping track of is referred to as the process context. This might be the terminal you are running on or what files you have open. The context even includes the internal state of the CPU, that is, what the content of each register is.
What happens when a process’s time slice has run out or for some other reason another process gets to run? If things go right (and they usually do), eventually that process gets a turn again. However, to do things right, the process must be allowed to return to the exact place where it left off. Any difference could result in disaster.
You may have heard of the classic banking problem concerning deducting from your account. If the process returned to a place before it made the deduction, you would deduct twice. If the process hadn’t yet made the deduction but started up again at a point after which it would have made the deduction, it appears as though the deduction was made. Good for you, but not so good for the bank. Therefore, everything must be put back the way it was.
The processors used by Linux (Intel 80386 and later, as well as the DEC Alpha, and SPARC) have built-in capabilities to manage both multiple users and multiple tasks. We will get into the details of this in later chapters. For now, just be aware of the fact that the CPU assists the operating system in managing users and processes. This shows how multiple processes might look in memory:
Image – Processes using differing areas of memory. (interactive)
In addition to user processes, such as shells, text editors, and databases, there are system processes running. These are processes that were started by the system. Several of these deal with managing memory and scheduling turns on the CPU. Others deal with delivering mail, printing, and other tasks that we take for granted. In principle, both of these kinds of processes are identical. However, system processes can run at much higher priorities and therefore run more often than user processes.
Typically a system process of this kind is referred to as a daemon process or background process because they run behind the scenes (i.e. in the background) without user intervention. It is also possible for a user to put one of his or her processes in the background. This is done by using the ampersand (&) metacharacter at the end of the command line. (I’ll talk more about metacharacters in the section on shells .)
What normally happens when you enter a command is that the shell will wait for that command to finish before it accepts a new command. By putting a command in the background, the shell does not wait, but rather is ready immediately for the next command. If you wanted, you could put the next command in the background as well.
I have talked to customers who have complained about their systems grinding to a halt after they put dozens of processes in the background. The misconception is that because they didn’t see the process running, it must not be taking up any resources. (Out of sight, out of mind.) The issue here is that even though the process is running in the background and you can’t see it, it still behaves like any other process.