2 T HE A BSTRACTION : T HE P ROCESS

T IP : U SE T IME S HARING ( AND S PACE S HARING )

Time sharing is a basic technique used by an OS to share a resource. By
allowing the resource to be used for a little while by one entity, and then
a little while by another, and so forth, the resource in question (e.g., the
CPU, or a network link) can be shared by many. The counterpart of time
sharing is space sharing, where a resource is divided (in space) among
those who wish to use it. For example, disk space is naturally a space-
shared resource; once a block is assigned to a file, it is normally not as-
signed to another file until the user deletes the original file.

switch, which gives the OS the ability to stop running one program and
start running another on a given CPU; this time-sharing mechanism is
employed by all modern OSes.
On top of these mechanisms resides some of the intelligence in the
OS, in the form of policies. Policies are algorithms for making some
kind of decision within the OS. For example, given a number of possi-
ble programs to run on a CPU, which program should the OS run? A
scheduling policy in the OS will make this decision, likely using histori-
cal information (e.g., which program has run more over the last minute?),
workload knowledge (e.g., what types of programs are run), and perfor-
mance metrics (e.g., is the system optimizing for interactive performance,
or throughput?) to make its decision.

4.1 The Abstraction: A Process

The abstraction provided by the OS of a running program is something
we will call a process. As we said above, a process is simply a running
program; at any instant in time, we can summarize a process by taking an
inventory of the different pieces of the system it accesses or affects during
the course of its execution.
To understand what constitutes a process, we thus have to understand
its machine state: what a program can read or update when it is running.
At any given time, what parts of the machine are important to the execu-
tion of this program?
One obvious component of machine state that comprises a process is
its memory. Instructions lie in memory; the data that the running pro-
gram reads and writes sits in memory as well. Thus the memory that the
process can address (called its address space) is part of the process.
Also part of the process’s machine state are registers; many instructions
explicitly read or update registers and thus clearly they are important to
the execution of the process.
Note that there are some particularly special registers that form part
of this machine state. For example, the program counter (PC) (sometimes
called the instruction pointer or IP) tells us which instruction of the pro-
gram will execute next; similarly a stack pointer and associated frame

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]
 2 T HE A BSTRACTION : T HE P ROCESS

T IP : U SE T IME S HARING ( AND S PACE S HARING )

Time sharing is a basic technique used by an OS to share a resource. By
allowing the resource to be used for a little while by one entity, and then
a little while by another, and so forth, the resource in question (e.g., the
CPU, or a network link) can be shared by many. The counterpart of time
sharing is space sharing, where a resource is divided (in space) among
those who wish to use it. For example, disk space is naturally a space-
shared resource; once a block is assigned to a file, it is normally not as-
signed to another file until the user deletes the original file.

switch, which gives the OS the ability to stop running one program and
start running another on a given CPU; this time-sharing mechanism is
employed by all modern OSes.
On top of these mechanisms resides some of the intelligence in the
OS, in the form of policies. Policies are algorithms for making some
kind of decision within the OS. For example, given a number of possi-
ble programs to run on a CPU, which program should the OS run? A
scheduling policy in the OS will make this decision, likely using histori-
cal information (e.g., which program has run more over the last minute?),
workload knowledge (e.g., what types of programs are run), and perfor-
mance metrics (e.g., is the system optimizing for interactive performance,
or throughput?) to make its decision.

4.1 The Abstraction: A Process

The abstraction provided by the OS of a running program is something
we will call a process. As we said above, a process is simply a running
program; at any instant in time, we can summarize a process by taking an
inventory of the different pieces of the system it accesses or affects during
the course of its execution.
To understand what constitutes a process, we thus have to understand
its machine state: what a program can read or update when it is running.
At any given time, what parts of the machine are important to the execu-
tion of this program?
One obvious component of machine state that comprises a process is
its memory. Instructions lie in memory; the data that the running pro-
gram reads and writes sits in memory as well. Thus the memory that the
process can address (called its address space) is part of the process.
Also part of the process’s machine state are registers; many instructions
explicitly read or update registers and thus clearly they are important to
the execution of the process.
Note that there are some particularly special registers that form part
of this machine state. For example, the program counter (PC) (sometimes
called the instruction pointer or IP) tells us which instruction of the pro-
gram will execute next; similarly a stack pointer and associated frame

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]
 2 T HE A BSTRACTION : T HE P ROCESS

T IP : U SE T IME S HARING ( AND S PACE S HARING )

Time sharing is a basic technique used by an OS to share a resource. By
allowing the resource to be used for a little while by one entity, and then
a little while by another, and so forth, the resource in question (e.g., the
CPU, or a network link) can be shared by many. The counterpart of time
sharing is space sharing, where a resource is divided (in space) among
those who wish to use it. For example, disk space is naturally a space-
shared resource; once a block is assigned to a file, it is normally not as-
signed to another file until the user deletes the original file.

switch, which gives the OS the ability to stop running one program and
start running another on a given CPU; this time-sharing mechanism is
employed by all modern OSes.
On top of these mechanisms resides some of the intelligence in the
OS, in the form of policies. Policies are algorithms for making some
kind of decision within the OS. For example, given a number of possi-
ble programs to run on a CPU, which program should the OS run? A
scheduling policy in the OS will make this decision, likely using histori-
cal information (e.g., which program has run more over the last minute?),
workload knowledge (e.g., what types of programs are run), and perfor-
mance metrics (e.g., is the system optimizing for interactive performance,
or throughput?) to make its decision.

4.1 The Abstraction: A Process

The abstraction provided by the OS of a running program is something
we will call a process. As we said above, a process is simply a running
program; at any instant in time, we can summarize a process by taking an
inventory of the different pieces of the system it accesses or affects during
the course of its execution.
To understand what constitutes a process, we thus have to understand
its machine state: what a program can read or update when it is running.
At any given time, what parts of the machine are important to the execu-
tion of this program?
One obvious component of machine state that comprises a process is
its memory. Instructions lie in memory; the data that the running pro-
gram reads and writes sits in memory as well. Thus the memory that the
process can address (called its address space) is part of the process.
Also part of the process’s machine state are registers; many instructions
explicitly read or update registers and thus clearly they are important to
the execution of the process.
Note that there are some particularly special registers that form part
of this machine state. For example, the program counter (PC) (sometimes
called the instruction pointer or IP) tells us which instruction of the pro-
gram will execute next; similarly a stack pointer and associated frame

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]
 T HE A BSTRACTION : T HE P ROCESS 5

the machinery of paging and swapping, topics we’ll cover in the future
when we discuss the virtualization of memory. For now, just remember
that before running anything, the OS clearly must do some work to get
the important program bits from disk into memory.
Once the code and static data are loaded into memory, there are a few
other things the OS needs to do before running the process. Some mem-
ory must be allocated for the program’s run-time stack (or just stack).
As you should likely already know, C programs use the stack for local
variables, function parameters, and return addresses; the OS allocates
this memory and gives it to the process. The OS will also likely initial-
ize the stack with arguments; specifically, it will fill in the parameters to
the main() function, i.e., argc and the argv array.
The OS may also allocate some memory for the program’s heap. In C
programs, the heap is used for explicitly requested dynamically-allocated
data; programs request such space by calling malloc() and free it ex-
plicitly by calling free(). The heap is needed for data structures such as
linked lists, hash tables, trees, and other interesting data structures. The
heap will be small at first; as the program runs, and requests more mem-
ory via the malloc() library API, the OS may get involved and allocate
more memory to the process to help satisfy such calls.
The OS will also do some other initialization tasks, particularly as re-
lated to input/output (I/O). For example, in U NIX systems, each process
by default has three open file descriptors, for standard input, output, and
error; these descriptors let programs easily read input from the terminal
and print output to the screen. We’ll learn more about I/O, file descrip-
tors, and the like in the third part of the book on persistence.
By loading the code and static data into memory, by creating and ini-
tializing a stack, and by doing other work as related to I/O setup, the OS
has now (finally) set the stage for program execution. It thus has one last
task: to start the program running at the entry point, namely main(). By
jumping to the main() routine (through a specialized mechanism that
we will discuss next chapter), the OS transfers control of the CPU to the
newly-created process, and thus the program begins its execution.

4.4 Process States

Now that we have some idea of what a process is (though we will
continue to refine this notion), and (roughly) how it is created, let us talk
about the different states a process can be in at a given time. The notion
that a process can be in one of these states arose in early computer systems
[DV66,V+65]. In a simplified view, a process can be in one of three states:

• Running: In the running state, a process is running on a processor.

This means it is executing instructions.
• Ready: In the ready state, a process is ready to run but for some
reason the OS has chosen not to run it at this given moment.

T HREE
© 2008–23, A RPACI -D USSEAU
E ASY
P IECES
 T HE A BSTRACTION : T HE P ROCESS 5

the machinery of paging and swapping, topics we’ll cover in the future
when we discuss the virtualization of memory. For now, just remember
that before running anything, the OS clearly must do some work to get
the important program bits from disk into memory.
Once the code and static data are loaded into memory, there are a few
other things the OS needs to do before running the process. Some mem-
ory must be allocated for the program’s run-time stack (or just stack).
As you should likely already know, C programs use the stack for local
variables, function parameters, and return addresses; the OS allocates
this memory and gives it to the process. The OS will also likely initial-
ize the stack with arguments; specifically, it will fill in the parameters to
the main() function, i.e., argc and the argv array.
The OS may also allocate some memory for the program’s heap. In C
programs, the heap is used for explicitly requested dynamically-allocated
data; programs request such space by calling malloc() and free it ex-
plicitly by calling free(). The heap is needed for data structures such as
linked lists, hash tables, trees, and other interesting data structures. The
heap will be small at first; as the program runs, and requests more mem-
ory via the malloc() library API, the OS may get involved and allocate
more memory to the process to help satisfy such calls.
The OS will also do some other initialization tasks, particularly as re-
lated to input/output (I/O). For example, in U NIX systems, each process
by default has three open file descriptors, for standard input, output, and
error; these descriptors let programs easily read input from the terminal
and print output to the screen. We’ll learn more about I/O, file descrip-
tors, and the like in the third part of the book on persistence.
By loading the code and static data into memory, by creating and ini-
tializing a stack, and by doing other work as related to I/O setup, the OS
has now (finally) set the stage for program execution. It thus has one last
task: to start the program running at the entry point, namely main(). By
jumping to the main() routine (through a specialized mechanism that
we will discuss next chapter), the OS transfers control of the CPU to the
newly-created process, and thus the program begins its execution.

4.4 Process States

Now that we have some idea of what a process is (though we will
continue to refine this notion), and (roughly) how it is created, let us talk
about the different states a process can be in at a given time. The notion
that a process can be in one of these states arose in early computer systems
[DV66,V+65]. In a simplified view, a process can be in one of three states:

• Running: In the running state, a process is running on a processor.

This means it is executing instructions.
• Ready: In the ready state, a process is ready to run but for some
reason the OS has chosen not to run it at this given moment.

T HREE
© 2008–23, A RPACI -D USSEAU
E ASY
P IECES
 T HE A BSTRACTION : T HE P ROCESS 5

the machinery of paging and swapping, topics we’ll cover in the future
when we discuss the virtualization of memory. For now, just remember
that before running anything, the OS clearly must do some work to get
the important program bits from disk into memory.
Once the code and static data are loaded into memory, there are a few
other things the OS needs to do before running the process. Some mem-
ory must be allocated for the program’s run-time stack (or just stack).
As you should likely already know, C programs use the stack for local
variables, function parameters, and return addresses; the OS allocates
this memory and gives it to the process. The OS will also likely initial-
ize the stack with arguments; specifically, it will fill in the parameters to
the main() function, i.e., argc and the argv array.
The OS may also allocate some memory for the program’s heap. In C
programs, the heap is used for explicitly requested dynamically-allocated
data; programs request such space by calling malloc() and free it ex-
plicitly by calling free(). The heap is needed for data structures such as
linked lists, hash tables, trees, and other interesting data structures. The
heap will be small at first; as the program runs, and requests more mem-
ory via the malloc() library API, the OS may get involved and allocate
more memory to the process to help satisfy such calls.
The OS will also do some other initialization tasks, particularly as re-
lated to input/output (I/O). For example, in U NIX systems, each process
by default has three open file descriptors, for standard input, output, and
error; these descriptors let programs easily read input from the terminal
and print output to the screen. We’ll learn more about I/O, file descrip-
tors, and the like in the third part of the book on persistence.
By loading the code and static data into memory, by creating and ini-
tializing a stack, and by doing other work as related to I/O setup, the OS
has now (finally) set the stage for program execution. It thus has one last
task: to start the program running at the entry point, namely main(). By
jumping to the main() routine (through a specialized mechanism that
we will discuss next chapter), the OS transfers control of the CPU to the
newly-created process, and thus the program begins its execution.

4.4 Process States

Now that we have some idea of what a process is (though we will
continue to refine this notion), and (roughly) how it is created, let us talk
about the different states a process can be in at a given time. The notion
that a process can be in one of these states arose in early computer systems
[DV66,V+65]. In a simplified view, a process can be in one of three states:

• Running: In the running state, a process is running on a processor.

This means it is executing instructions.
• Ready: In the ready state, a process is ready to run but for some
reason the OS has chosen not to run it at this given moment.

T HREE
© 2008–23, A RPACI -D USSEAU
E ASY
P IECES
8 T HE A BSTRACTION : T HE P ROCESS

// the registers xv6 will save and restore

// to stop and subsequently restart a process
struct context {
int eip;
int esp;
int ebx;
int ecx;
int edx;
int esi;
int edi;
int ebp;
};

// the different states a process can be in

enum proc_state { UNUSED, EMBRYO, SLEEPING,
RUNNABLE, RUNNING, ZOMBIE };

// the information xv6 tracks about each process

// including its register context and state
struct proc {
char *mem; // Start of process memory
uint sz; // Size of process memory
char *kstack; // Bottom of kernel stack
// for this process
enum proc_state state; // Process state
int pid; // Process ID
struct proc *parent; // Parent process
void *chan; // If !zero, sleeping on chan
int killed; // If !zero, has been killed
struct file *ofile[NOFILE]; // Open files
struct inode *cwd; // Current directory
struct context context; // Switch here to run process
struct trapframe *tf; // Trap frame for the
// current interrupt
};

Figure 4.5: The xv6 Proc Structure

stopped process, the contents of its registers. When a process is stopped,
its registers will be saved to this memory location; by restoring these reg-
isters (i.e., placing their values back into the actual physical registers), the
OS can resume running the process. We’ll learn more about this technique
known as a context switch in future chapters.
You can also see from the figure that there are some other states a pro-
cess can be in, beyond running, ready, and blocked. Sometimes a system
will have an initial state that the process is in when it is being created.
Also, a process could be placed in a final state where it has exited but

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]
8 T HE A BSTRACTION : T HE P ROCESS

// the registers xv6 will save and restore

// to stop and subsequently restart a process
struct context {
int eip;
int esp;
int ebx;
int ecx;
int edx;
int esi;
int edi;
int ebp;
};

// the different states a process can be in

enum proc_state { UNUSED, EMBRYO, SLEEPING,
RUNNABLE, RUNNING, ZOMBIE };

// the information xv6 tracks about each process

// including its register context and state
struct proc {
char *mem; // Start of process memory
uint sz; // Size of process memory
char *kstack; // Bottom of kernel stack
// for this process
enum proc_state state; // Process state
int pid; // Process ID
struct proc *parent; // Parent process
void *chan; // If !zero, sleeping on chan
int killed; // If !zero, has been killed
struct file *ofile[NOFILE]; // Open files
struct inode *cwd; // Current directory
struct context context; // Switch here to run process
struct trapframe *tf; // Trap frame for the
// current interrupt
};

Figure 4.5: The xv6 Proc Structure

stopped process, the contents of its registers. When a process is stopped,
its registers will be saved to this memory location; by restoring these reg-
isters (i.e., placing their values back into the actual physical registers), the
OS can resume running the process. We’ll learn more about this technique
known as a context switch in future chapters.
You can also see from the figure that there are some other states a pro-
cess can be in, beyond running, ready, and blocked. Sometimes a system
will have an initial state that the process is in when it is being created.
Also, a process could be placed in a final state where it has exited but

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]
8 T HE A BSTRACTION : T HE P ROCESS

// the registers xv6 will save and restore

// to stop and subsequently restart a process
struct context {
int eip;
int esp;
int ebx;
int ecx;
int edx;
int esi;
int edi;
int ebp;
};

// the different states a process can be in

enum proc_state { UNUSED, EMBRYO, SLEEPING,
RUNNABLE, RUNNING, ZOMBIE };

// the information xv6 tracks about each process

// including its register context and state
struct proc {
char *mem; // Start of process memory
uint sz; // Size of process memory
char *kstack; // Bottom of kernel stack
// for this process
enum proc_state state; // Process state
int pid; // Process ID
struct proc *parent; // Parent process
void *chan; // If !zero, sleeping on chan
int killed; // If !zero, has been killed
struct file *ofile[NOFILE]; // Open files
struct inode *cwd; // Current directory
struct context context; // Switch here to run process
struct trapframe *tf; // Trap frame for the
// current interrupt
};

Figure 4.5: The xv6 Proc Structure

stopped process, the contents of its registers. When a process is stopped,
its registers will be saved to this memory location; by restoring these reg-
isters (i.e., placing their values back into the actual physical registers), the
OS can resume running the process. We’ll learn more about this technique
known as a context switch in future chapters.
You can also see from the figure that there are some other states a pro-
cess can be in, beyond running, ready, and blocked. Sometimes a system
will have an initial state that the process is in when it is being created.
Also, a process could be placed in a final state where it has exited but

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]