OPERATING SYSTEMS

DESIGN AND IMPLEMENTATION

Third Edition
ANDREW S. TANENBAUM
ALBERT S. WOODHULL

Chapter 2
Processes
 The Process Model
• Process is an abstraction of a running program

• All modern computer can do several things at the same time

• In a multiprogramming system, the CPU also switches from

program to program, running each for tens or hundreds of
milliseconds

•Strictly speaking, at any instant of time, the CPU is running only

one program

• In the course of 1 second, it may work on several programs,

giving user the illusion of parallelism
 The Process Model
• We are assuming a multiprogramming OS that can switch from
one process to another.

• Sometimes this is called pseudoparallelism since one has the

illusion of a parallel processor.

• The other possibility is real parallelism in which two or more

processes are actually running at once because the computer system
is a parallel processor, i.e., has more than one processor.

• We do not study real parallelism (parallel processing, distributed

systems, multiprocessors, etc) in this course.
 The Process Model
• It is contrast with the true hardware parallelism of multiprocessor
system, which have two or more CPUs sharing the same physical
memory

• Here in this model it is organized into number of sequential

processes, or just processes for short

• A process is just executing the program

• The rapid switching back and forth is called Multiprogramming (a)

 The Process Model

Figure 1.(a) Multiprogramming of four programs.

 The Process Model

Figure 1.(b) Conceptual model of four independent, sequential processes (each running
independently)
 The Process Model (3)

Figure 1.(c) Only one program is active at any instant.

 The Process Model
• All the processes have made progress, but at any given instant only
one process is actually running

• Processes must not be programmed with built-in assumption about

timing
 The Process Model
• Even through in actuality there are many processes running at once,
the OS gives each process the illusion that it is running alone.
Virtual time: The time used by just this processes. Virtual time progresses at
a rate independent of other processes. Actually, this is false, the virtual time is
typically incremented a little during systems calls used for process switching;
so if there are more other processors more ``overhead'' virtual time occurs.
Virtual memory: The memory as viewed by the process. Each process
typically believes it has a contiguous chunk of memory starting at location
zero. Of course this can't be true of all processes (or they would be using the
same memory) and in modern systems it is actually true of no processes (the
memory assigned is not contiguous and does not include location zero).

•Virtual time and virtual memory are examples of abstractions

provided by the operating system to the user processes so that the
latter ``sees'' a more pleasant virtual machine than actually exists.
 Process Creation
Principal events that cause processes to be created:
1. System initialization.
2. Execution of a process creation system call a running
process.
3. A user request to create a new process.
4. Initiation of a batch job.
 Process Creation
• Process Initialization

• When an OS is booted, often several processes are created

• Some of them are foreground processes, that is, processes

that interact with (human) users and perform work for them

• Other are background processes, which are not associated

with particular users, but instead have some specific
function
 Process Creation
• Process creation system call

• System calls to create one or more processes to help the

running process doing its job

• Creating new process is useful when the work to be done

can easily be formulated in term of several related, but
otherwise independent interacting processes
 Process Creation
• User request

• In interactive systems, user can start a program by typing a

command

• Initiation of batch job

• Users can submit batch jobs to the system (possibly

remotely)

• When the OS decides that it has the resources to run

another job  OS creates a new process and runs the next
job from the input queue in it
 Process Termination
• Conditions that cause a process to terminate:
− Normal exit (voluntary): the process work is done
− Error exit (voluntary): the error is caused by the process.
Example an Illegal operations in program. Examples include
executing an illegal instruction, referencing
nonexistent memory, or dividing by zero
Fatal error (involuntary): the process discovers a error for
example compiling a foo.c and this file doesn’t exists
compiler simply exits
− Killed by another process (involuntary): one process executes
a system call telling the OS to kill some other process.
 Process States
• Each process is an independent entity, with its own program
counter registers, stack, open files, alarms, and other internal state
• Processes often need to interact, communicate, and synchronize
with other processes
• One process may generate some output that another process uses as
input
 Process States
• Possible process states:
1. Running: actually using the CPU at that instant

2. Ready: runnable; temporarily stopped to let another process run

3. Blocked: unable to run until some external event happens

• Logically, the first two states are similar. In both case is willing to
run
• only in the second one, there is temporarily no CPU available for
it.
 Process States

Figure 2 A process can be in running, blocked, or ready state.

Transitions between these states are as shown.
 Process States
• 4 transitions are possible among these states:
− Transition 1:occurs when a process discovers that it can’t
continue.
− Transition 2: the process scheduler (part of OS) decide that
the running process has run long enough and it is time to let
another process have some CPU time.
− Transition 3: occurs when it is time for the process to get the
CPU to run again.
− Transition 4: occurs when the external event for which a
process was waiting happens.
 Process States
• To implement the process model, the OS maintains a table called
process table (or process control block) with one entry per
process.

• Each process entry contains information about the process that must
be saved when the process is switched from running and ready state
 it can be restarted later as if it had never been stopped.

• Example of these information: process state, program counter, stack

pointer, memory allocation, the status of its open files, ...etc.
Figure 3 The lowest layer of a process-structured operating system

All the interrupt handling and details of

actually starting and stopping processes are hidden away
in the scheduler

the "scheduler" is not the only thing in the lowest layer,

 Implementation of Processes
Kernel Process management

Figure 4. Some of the fields of the MINIX 3 process table.

 Interrupts
• Interruption is a signal to a processor indicating that an
asynchronous event has occurred.
• The current sequence of instructions is temporarily suspended, and a
sequence appropriate to the interruption is started in its place.
• Its purpose is to alert the OS when any special event occurs so that it
can suspend its current activity and deal with the new situation
• Interrupt descriptor table is a data structure associated with each I/O
device class
• Interrupt vector is the most important entry in the interrupt
descriptor table. It contains the address of the interrupt service
procedure (handler).
•Suppose that user process 23 is running when a disk interrupt occurs.
 Interrupts

Figure 5 Skeleton of what the lowest level of the operating system does when an
interrupt occurs.
 Threads
• A threads are a way for a program to fork (or split) itself into two
or more simultaneously (or pseudo-simultaneously) running
tasks.

• Threads and processes differ from one OS to another, but in

general, the way that a thread is created and shares its resources
is different from the way a process does.

• Multiple threads can be executed in parallel on many computer

systems.

• This multithreading generally occurs by time slicing , wherein a

single processor switches between different threads, in which
case the processing is not literally simultaneous, for the single
processor is really doing only one thing at a time.
 Threads
• This switching can happen so fast as to give the illusion of
simultaneity to an end user. You can run multiple programs at
once, such as typing in a document editor while listening to music
in an audio playback program;

• though the user experiences these things as simultaneous, in

truth, the processor quickly switches back and forth between
these separate processes.

• On a multiprocessor system, now coming into general use,

threading can be achieved via multiprocessing, wherein different
threads and processes can run literally simultaneously on
different processors or cores.
 Threads
• Many modern OS directly support both time-sliced and
multiprocessor threading with a process scheduler.

• The OS Kernel allows programmers to manipulate threads via the

system calls interface.

• Absent that, programs can still implement threading by using

timers, signals, or other methods to interrupt their own
execution and hence perform a sort of ad hoc time-slicing. These
are sometimes called user-space threads.
 Threads
• In traditional OS, each process has an address space and a single
thread of control

• There are often situations in which it is desirable to have multiple

threads of control in the same address space running in quasi-
parallel,  they were separate processes (except for the shared
address space)

•These threads of control are usually just called threads (or

lightweight processes)
 Threads
• Process are used to group resources together

• Threads are the entities scheduled for execution on the CPU

• What threads add to the process model is to allow multiple

executions to take place in the same process environment, to a large
degree independent of one another
 Threads
•We see 3 traditional processes. Each process has its own address
space and a single thread of control. In this case each thread operates
in a different address space.

Figure 6 (a) Three processes each with one thread.

 Threads
Here we see single process with three threads of control. In this
case all three threads share the same address space.

Figure 6 (b) One process with three threads.

(Website is an good example of multiple threads)
 Threads
In case of multiple threads:

Figure 7. The first column lists some items shared by all threads in a process. The
second one lists some items private to each thread.
InterProcess Communication (IPC)
• Process frequently need to communicate with other processes in
well-structured way not using interruption.
•Example: Shell pipeline
•3 issues
− How one process can pass information to another
− Making sure that 2 or more processes do not get into each
other’s way when engaging in critical activities
− Proper sequencing when dependencies are present: process A
produce data and process B print it  B must wait A has
produced data
 Race Conditions
• In some OS, processes that are working together may share some
common storage that each one can read and write.

• The shared storage may be in main memory or a shared file.

• Consider Print spooler example. When a process wants to print a

file  it enters the file name in a special spooler directory.

• Another process, the printer daemon, periodically checks to see if

there is any files to be printed, and if so removes their names from
the directory.
 Race Conditions

Two processes want to access shared memory at the same time.

 Race Conditions
•A race condition occurs when two processes can interact and the
outcome depends on the order in which the processes execute.

•Imagine two processes both accessing x, which is initially 10.

1. One process is to execute x <-- x+1

2. The other is to execute x <-- x-1
3. When both are finished x should be 10
4. But we might get 9 and might get 11!
5. Show how this can happen ((x <-- x+1) is not atomic)
 Race Conditions

race condition is a situation where two or more processes are

reading or writing some shared data and the final results depends
on who runs precisely when
 Critical Sections
• How do we avoid race condition?  We need to prevent sharing
more than one processes to shared things

• Difficulty occurred because process B started using one of the shared

variables before process A was finished with it

• Solution: Mutual Exclusion

• Mutual Exclusion: some way of making sure that if one process is

using a shared variable or file, the other processes will be excluded
from doing the same thing.

•The choice of appropriate primitive operations for achieving mutual

exclusion is a major design issue in any OS
 Critical Sections
• Critical region or critical section. Is a part of the program where
the shared memory is accessed.

• To avoid race condition, we could arrange matters such that no 2

processes were ever in their critical regions at the same time

• This is not sufficient for having parallel processes cooperate

correctly and efficiently using shared data
 Critical Sections
Necessary to avoid race conditions:
1. No two processes may be simultaneously inside their critical regions.

2. No assumptions may be made about speeds or the number of CPUs.

3. No process running outside its critical region may block other processes.

4. No process should have to wait forever to enter its critical region.

Mutual Exclusion with Busy Waiting
• The operating system can choose not to preempt itself.

• That is, no preemption for system processes (if the OS is client

server) or for processes running in system mode (if the OS is self
service).

• Forbidding preemption for system processes

• Would prevent the problem above where x<--x+1 not being
atomic
• Crashed the printer spooler if the spooler is part of the OS.
Mutual Exclusion with Busy Waiting

Figure 9 Mutual exclusion using critical regions.

Mutual Exclusion with Busy Waiting
But this is not adequate
• Does not work for user programs. So the spooler would not be
helped.
• Does not prevent conflicts between the main line OS and interrupt
handlers
1. This conflict could be prevented by blocking interrupts while
the mail line is in its critical section.
2. Indeed, blocking interrupts is often done for exactly this
reason.
3. Do not want to block interrupts for too long or the system will
seem unresponsive
• Does not work if the system has several processors
1. Both main lines can conflict
2. One processor cannot block interrupts on the other
 Disabling interrupts

• Disabling interruption is a way to achieve mutual exclusions

• Disabling interruption is the simple solution

• Each process disable all interrupts just after entering its critical
region and re-enable them just before leaving it.
 Disabling interrupts
•Lots of disadvantages:
− Give the user processes the power to turn off the interrupts. Problem: if the
user turn on the interrupts and never turn them again  end of the system
− In multiprogramming system with multiple CPU. Disabling interrupts
affects only the CPU that executed the disable instructions. The other CPU will
continue running and can access the shared memory.

•Disabling interrupts is useful technique within OS itself but not

appropriate as a general mutual exclusion for user processes
 Lock variable
• Consider having single, shared (lock) variable, initially 0.
• When a process wants to enter its critical region, it first test the
lock.
• If the lock is 0, the process sets it to 1 and enters the critical
region.
• If the lock is already 1 then process just wait until it becomes 0.
• Disadvantage
− Same problem fatal flaw that we saw in spooling directory: 2 processes in
the critical section
 Strict Alternation
• Use an integer turn, initially 0, keeps track of whose turn it is to
enter the critical region and examine or update the shared memory.

• Continuously testing a variable until some value appears is called

busy waiting.

•Disadvantages
− CPU time wastage
− Violates condition 3
 Strict Alternation

Figure10. solution to the critical region problem. (a) Process 0. (b) Process 1.
In both cases, be sure to note the semicolons terminating the while statements.
 Peterson’s Solution

{ ...

Figure 11 Peterson’s solution for achieving mutual exclusion.

 Peterson’s Solution

Figure 2-11 Peterson’s solution for achieving

mutual exclusion.
Peterson’s Solution
 The TSL (Test, Set Lock) Instruction

Figure 12. Entering and leaving a critical region using the TSL instruction.
 Tanenbaum & Woodhull, Operating
Systems: Design and Implementation, (c)
2006 Prentice-Hall, Inc. All rights reserved.
The Producer-Consumer Problem
• Two classes of processes
– Producers, which produce times and insert them into a buffer.
– Consumers, which remove items and consume them.

• What if the producer encounters a full buffer? Answer: Block it.

• What if the consumer encounters an empty buffer? Answer: Block it.

• The solution is for the produce to go to sleep, to be awakened when

the consumer has removed one or more items. Similarly vise versa.

• Also called the bounded buffer problem.

The Producer-Consumer Problem

Figure 2-13. The producer-consumer problem

with a fatal race condition.

...
The Producer-Consumer Problem
...
Figure 2-13. The producer-consumer problem
with a fatal race condition
 Semaphore
• The solution to both of these shortcomings is to remove the
restriction to a binary variable and define a generalized or
counting variable.

• Earlier situation was up to 1965. E. w. Dijkstra, suggests using a

integer variable to count the number of wakeups saved for
future use.

• In this proposal new variable type, called a semaphore, was

introduced.
 Semaphore
• A semaphore S takes on non-negative integer values
• Two operations are supported P(S) and V(S)
• P(S) is while (S=0) S–
• where finding S>0 and decrementing S is atomic
• That is, wait until the gate is open (positive), then run through and
atomically close the gate one unit
• V(S) is simply S++
• Said another way, it is not possible for two processes doing simultaneously
P(S) simultaneously to both see the same positive value of S unless a V(S) is
also simultaneous.
• These semaphores can solve what we call the semi-critical-section problem,
where you permit up to k processes in the section. When k=1 we have the
original critical-section problem.
 Tanenbaum & Woodhull, Operating
Systems: Design and Implementation, (c)
2006 Prentice-Hall, Inc. All rights reserved.
The Producer-Consumer Problem

...
Figure 2-14. The producer-consumer problem using semaphores.
The Producer-Consumer Problem
...
Figure 2-14. The producer-consumer problem
using semaphores.
 Monitors
• When the semaphore’s ability to count is not needed, a simplified
version of the semaphore, called mutex, is sometimes used.
• Mutexes are good only for managing mutual exclusion to some
shared resources or piece of code.
• A mutex is a variable that can be in one of two states: unlocked
or locked.
• If the buffer were completely full, the producer would block, with
mutex set to 0.
• Consequently, the next time the consumer tried to access the
buffer, it would do a down on mutex, now 0 and block too.
 Monitors
• Problem: Both processes would stay blocked forever and no
more work would ever be done. This unfortunate situation is
called a deadlock.
• Solution: To make it easer, new approach to deal with it called
monitor in 1973 and 1974.
• A monitor is a collection of procedures, variables, and data
structures that are all grouped together in a special kind of
module or package.
Monitors

Figure 15. A monitor.

Monitors
 Monitors

Figure 16. An outline of the producer-consumer problem with monitors.

Only one monitor procedure at a time is active.
The buffer has N slots
 Message Passing
• This method of inter-process communication uses two primitives,
send and receive.
• The two primitives, which like semaphores and unlike monitors, are
system calls rather than language constructs.

...

Figure 2-17. The producer-consumer problem with N messages.

 Message Passing
...
Figure 2-17. The producer-consumer problem
with N messages.
 The Dining Philosophers Problem
• A classical problem from Dijkstra
• 5 philosophers sitting at a round table
• A philosopher’s life consists of alternate periods of eating and thinking
• Each has a plate of spaghetti
• There is a fork between each two a philosophers
• When a philosopher gets hungry, he tries to acquire his left and right
fork, one at a time, in either order
• Need two forks to eat
• If successful in acquiring two forks, s/he eats for a while, then puts
down the forks and continue to think.

• What algorithm do you use for access to the shared resource (the
forks)?

• The obvious solution (pick up right; pick up left) deadlocks.

The Dining Philosophers Problem

Figure 2-18. Lunch time in the Philosophy Department.

 The Dining Philosophers Problem

Figure 2-19. A nonsolution to the dining

philosophers problem.

Figure 19. A non-solution to the dining philosophers problem.

 The Dining Philosophers Problem

...

Figure 20. A solution to the dining philosophers problem.

 The Dining Philosophers Problem
...

...
Figure 20. A solution to the dining philosophers problem.
 The Dining Philosophers Problem
...

Figure 20. A solution to the dining philosophers problem.

The Readers and Writers Problem
• Two classes of processes.
– Readers, which can work concurrently.

– Writers, which need exclusive access.

• Must prevent 2 writers from being concurrent.

• Must prevent a reader and a writer from being concurrent.
• Must permit readers to be concurrent when no writer is active.
• Variants
– Writer-priority readers/writers.

– Reader-priority readers/writers.
The Readers and Writers Problem

...
Figure 21. A solution to the readers and writers problem.
The Readers and Writers Problem
...

Figure 21. A solution to the readers and writers problem.

 Scheduling
• When more than one process is in the ready state there is only
one CPU available, the OS must decide which process to run first.

• The part of the OS that makes the choice is called the scheduler;

• The used algorithm is called the scheduling algorithm.

• Consider the old days, when using batch system, with one input in
the form of card images on a magnetic tape, the scheduling
algorithm was simple: just run the next job on the tape.

• With timesharing systems, the scheduling algorithm become more

complex, because there were generally multiple users waiting for
service. There may be one or more batch systems as well
 Process Behavior

Figure 22. Bursts of CPU usage alternate with periods of waiting for I/O.
(a) A CPU-bound process. (b) An I/O-bound process.
 When to Schedule
• When scheduling is absolutely required:

1. When a process exits.

2. When a process blocks on I/O, or a semaphore.

• In both these cases the process that had most recently been running
becomes unready, so another must be chosen to run next.
 When to Schedule
• When scheduling usually done (though not absolutely required)
1. When a new process is created. It make sense to reevaluate priorities at this
time. In some cases the parent may be able to request a different priority for
its child

2. When an I/O interrupt occurs. This usually means that an I/O device has
now completed its work. So some process that was blocked waiting for I/O
may now be ready to run.

3. When a clock interrupt occurs. This is an opportunity to decide whether the

currently running process has run too long. Scheduling algorithm can be
divided into two categories with respect to how they deal with clock
interrupts. A non-primitive scheduling algorithm picks a process to run and
then just lets it run until it blocks. A primitive scheduling algorithm picks a
process and lets it run for a maximum of some fixed time.
Categories of Scheduling Algorithms
• In different environments different scheduling algorithms are
needed.
• The situation arises because different application areas (different
kinds of OS) have different goals
• They are:
1. Batch
2. Interactive
3. Real Time
 Scheduling Algorithms

Figure23. Some goals of the scheduling algorithm under different circumstances.

 Scheduling Algorithms in Batch systems
In Batch Systems:
(1) First-Come First Served – simplest algorithm
(2) Shortest Job First – Scheduler picks the shorted job first (Figure 24)
(3) Shortest Remaining time Next – the scheduler always chooses the process
whose remaining run time is the shortest

Figure 24. An example of shortest job first scheduling.

(a) Running four jobs in the original order. (b) Running them in shortest job first order.
 Three Level Scheduling
Criteria for deciding which process to choose:
– How long has it been since the process was swapped in or out?
– How much CPU time has the process had recently?
– How big is the process? (Small ones do not get in the way.)
– How important is the process?
 Three Level Scheduling

Figure 2-25. Three-level scheduling.

Scheduling in interactive systems

• We will focus on the CPU scheduler and some common algorithms.

•The common scheduling algorithms are
 Round-Robin scheduling
 Priority Scheduling
 Round Robin Scheduling
 the Round-Robin scheduling is

• an important preemptive policy.

• Essentially the preemptive version of FCFS.
• The key parameter is the quantum size q.
• When a process is put into the running state a timer is set to q.
• If the timer goes off and the process is still running, the OS
preempts the process.
 This process is moved to the ready state, where it is placed at the rear
of the ready list (a queue).
 The process at the front of the ready list is removed from the ready
list and run (i.e., moves to state running).
 Round-Robin Scheduling
• When a process is created, it is placed at the rear of the ready list.

• As q gets large, RR approaches FCFS

• As q gets small, RR approaches PS (Processor Sharing)

• What value of q should we choose?

 Tradeoff
 Small q makes system more responsive.
 Large q makes system more efficient since less process
switching.
Scheduling in interactive systems

Figure 26. Round-robin scheduling. (a) The list of runnable processes.

(b) The list of runnable processes after B uses up its quantum.
 Priority Scheduling
• Round-robin scheduling makes the implicit assumption that all processes
are equally important.
• Frequently, the people who own and operate multi-user computers have
different ideas on that subject. At a University, the order may be dean first,
then professors, secretaries, and finally students.
• This need to take external factors into account leads to priority
scheduling.
• The basic idea is simple:
•each process is assign a priority
• and the runnable process with the highest priority is allowed to run.

• If many processes have the highest priority, use RR among them.

•Can have the priorities changed dynamically to favor processes holding

important resources
 Priority Scheduling

Figure 27. A scheduling algorithm with four priority classes.

 Scheduling in Real Time systems
• A Real-Time system is one in which time plays an essential role

• One or more physical devices external to the computer generate

stimuli and the computer must react to them within a fixed amount of
time

• Events in Real-Time system can be categorized as

• Periodic: occurring at regular interval

• Aperiodic: occurring unpredictably
Scheduling in Real Time systems
• A real-time systems are generally categorized as
hard real time, meaning there are absolute deadlines that
must be met
soft real time, meaning that missing an occasional deadline
is undesirable, but nevertheless tolerable.
• In both cases, real-time behavior is achieved by dividing the
program into a number of processes, each of whose behavior is
predictable and known in advance.
 Scheduling in Real Time systems
•Real–Time scheduling algorithms can be
•Static
− Make their scheduling decision before the system starts
running
− Works only if perfect information available in advanced about
the work needed to be done + deadlines that have to meet
•Dynamic
− Make their scheduling decisions at run time
− Haven’t restriction
 Thread Scheduling
•When several processes each have multiple threads  2 levels of
parallelism: processes and threads.
•Scheduling differs depending on whether user-level or kernel-level
threads are supported
•User-level threads 
•kernel is not aware of the existence of the threads
•Kernel select a process A and give the control for A
•The thread scheduler inside A decides which thread to run A1
•Since there are no clock interrupts to multiprogram threads  A1
continue running as long as it wants to.
 Thread Scheduling

(a)

Figure 28. (a) Possible scheduling of user-level threads with a 50-msec process
quantum and threads that run 5 msec per CPU burst.
 Thread Scheduling
• Kernel-level threads 
•kernel picks particular thread to run
•Kernel does not have to take into account which process the
thread belongs to, but it can if it wants to
•The thread is given a quantum and is forceably suspended if it
exceeds the quantum
•Since there are no clock interrupts to multiprogram threads  A1
continue running as long as it wants to.