Information Technology Reference
In-Depth Information
Processes, lightweight processes, and threads
The word “process”, like many terms in computer science, has evolved over time.
Although you will often be able to ignore this history, it can sometimes trip up the unwary
as systems built at different times will use the same word in significantly different ways.
A “process” was originally coined to mean what we now call a “thread” - some logical
sequence of instructions, executing either operating system or application code. The
concept of a process was developed as a way of simplifying the correct construction of
operating systems, for early systems that provided no protection between application
programs.
Organizing the operating system as a cooperating set of processes proved immensely
successful, and soon virtually every new operating system was built this way, including
systems that also provided protection against malicious or buggy user programs. At
the time, almost all user programs were simple single-threaded programs with only one
program counter and one stack, so there was no confusion. A process was what was
needed to run a program, that is, a single sequential execution stream with a protection
boundary.
As parallel computers became more popular, though, we once again needed a word
for a logical sequence of instructions. A multiprocessor program can have multiple
instruction sequences running in parallel, each with their own program counter, but all
cooperating together within a single protection boundary. For a time, these were called
“lightweight processes” (each a sequence of instructions cooperating inside a protection
boundary), but eventually the word “thread” became more widely used.
This leads to the current naming convention used in almost all modern operating
systems: a process executes a program, consisting of one or more threads running
inside a protection boundary.
focus on protection, and so we will limit our discussion to simple processes, each
with one program counter, code, data, heap, and stack.
Some programs consist of multiple concurrent activities, or threads. A web
browser, for example, might need to be able to receive user input at the same
time it is also drawing the screen or receiving input from the network. Each of
these separate activities has its own program counter and stack but operates on
the same code and data as the other threads. The operating system multiplexes
threads running in a process, in much the same way that the operating system
multiplexes processes into physical memory. We will generalize on the process
abstraction to allow multiple activities in the same protection domain in the
next chapter.
