Chapter 3: Process

Synchronization

Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009

Module 6: Process Synchronization

‣ Backgroun
‣ The Critical-Section Proble
‣ Peterson’s Solutio
‣ Synchronization Hardwar
‣ Mutex Locks
‣ Semaphore
‣ Classic Problems of Synchronizatio
‣ Monitor
‣ Synchronization Examples
‣ Atomic Transactions

Operating System Concepts – 8th Edition 2 Silberschatz, Galvin and Gagne ©2009
s

 Objectives

‣ To introduce the critical-section problem, whose

solutions can be used to ensure the consistency of
shared dat

‣ To present both software and hardware solutions of the

critical-section proble

‣ To introduce the concept of an atomic transaction and

describe mechanisms to ensure atomicity

Operating System Concepts – 8th Edition 3 Silberschatz, Galvin and Gagne ©2009

Background

‣ Concurrent access to shared data may result in data

inconsistenc

‣ Maintaining data consistency requires mechanisms to

ensure the orderly execution of cooperating processe

‣ Suppose that we wanted to provide a solution to the

consumer-producer problem that fills all the buffers. We
can do so by having an integer counter that keeps track
of the number of full buffers. Initially, counter is set to 0. It
is incremented by the producer after it produces a new
buffer and is decremented by the consumer after it
consumes a buffer.

Operating System Concepts – 8th Edition 4 Silberschatz, Galvin and Gagne ©2009
a

 Shared Data

#define BUFFER_SIZE 10
typedef struct {
...
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
int counter = 0;

Operating System Concepts – 8th Edition 5 Silberschatz, Galvin and Gagne ©2009

Producer

while (true)
/* produce an item and put in nextProduced *
while (counter == BUFFER_SIZE
; // do nothin
buffer [in] = nextProduced
in = (in + 1) % BUFFER_SIZE
counter++
}

Operating System Concepts – 8th Edition 6 Silberschatz, Galvin and Gagne ©2009
{

 Consumer
while (true)
while (counter == 0
; // do nothin
nextConsumed = buffer[out]
out = (out + 1) % BUFFER_SIZE
counter--
/* consume the item in nextConsumed *
}

Operating System Concepts – 8th Edition 7 Silberschatz, Galvin and Gagne ©2009

Race Condition
‣ counter++ could be implemented as
register1 = counter
register1 = register1 + 1
counter = register
‣ counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register
‣ Consider this execution interleaving with “counter = 5” initially
S0: producer execute register1 = counter {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = counter {register2 = 5}
S3: consumer execute register2 = register2 - 1 {register2 = 4}
S4: producer execute counter = register1 {counter = 6 }
S5: consumer execute counter = register2 {counter = 4

Race condition: situation where several processes access and manipulate the same
data concurrently and the outcome of the execution depends on the particular order in
which the access takes place.

Operating System Concepts – 8th Edition 8 Silberschatz, Galvin and Gagne ©2009
2

 Critical Section Problem

‣ Consider system of n processes {p0, p1, … pn-1
‣ Each process has critical section segment of cod
✦ Process may be changing common variables, updating
table, writing file, et
✦ When one process in critical section, no other may be in
its critical sectio
‣ Critical section problem is to design protocol to solve thi
‣ Each process must ask permission to enter critical section in
entry section, may follow critical section with exit section,
then remainder sectio
‣ Especially challenging with preemptive kernels

Operating System Concepts – 8th Edition 9 Silberschatz, Galvin and Gagne ©2009

Critical Section

‣ General structure of process pi is

Operating System Concepts – 8th Edition 10 Silberschatz, Galvin and Gagne ©2009
n

 Solution to Critical-Section Problem

1. Mutual Exclusion - If process Pi is executing in its critical

section, then no other processes can be executing in their
critical section
2. Progress - If no process is executing in its critical section
and there exist some processes that wish to enter their
critical section, then the selection of the processes that will
enter the critical section next cannot be postponed
indefinitel
3. Bounded Waiting - A bound must exist on the number of
times that other processes are allowed to enter their critical
sections after a process has made a request to enter its
critical section and before that request is granted

Operating System Concepts – 8th Edition 11 Silberschatz, Galvin and Gagne ©2009

Peterson’s Solution

‣ Good algorithmic description of solving the proble

‣ Two process solutio
‣ Assume that the LOAD and STORE machine-language
instructions are atomic; that is, cannot be interrupte
‣ The two processes share two variables
✦ int turn;
✦ Boolean flag[2

‣ The variable turn indicates whose turn it is to enter the critical

sectio
‣ The flag array is used to indicate if a process is ready to enter the
critical section. flag[i] = true implies that process Pi is ready!

Operating System Concepts – 8th Edition 12 Silberschatz, Galvin and Gagne ©2009
n

 Algorithm for Process Pi

do {
flag[i] = TRUE;
‣ Provable that
turn = j;
1. Mutual exclusion is preserve
while (flag[j] && turn == j);
2. Progress requirement is
critical section satisfie
flag[i] = FALSE; 3. Bounded-waiting requirement
remainder section is met

} while (TRUE);

Operating System Concepts – 8th Edition 13 Silberschatz, Galvin and Gagne ©2009

Algorithm for Process Pi

P0 P1
do { do {
flag[0] = TRUE; flag[1] = TRUE;
turn = 1; turn = 0;
while (flag[1] && turn == 1); while (flag[0] && turn == 0);
critical section critical section
flag[0] = FALSE; flag[1] = FALSE;
remainder section remainder section
} while (TRUE); } while (TRUE);

Operating System Concepts – 8th Edition 14 Silberschatz, Galvin and Gagne ©2009

 Synchronization Hardware

‣ Many systems provide hardware support for critical section cod

‣ All solutions below based on idea of locking

✦ Protecting critical regions via lock

‣ Uniprocessors – could disable interrupt

✦ Currently running code would execute without preemptio
✦ Generally too inefficient on multiprocessor system
! Operating systems using this not broadly scalabl

‣ Modern machines provide special atomic hardware instruction

! Atomic = non-interruptabl
✦ Either test memory word or set value (TestAndSet()
✦ Or swap contents of two memory words (Swap())

Operating System Concepts – 8th Edition 15 Silberschatz, Galvin and Gagne ©2009

Solution to Critical-section
Problem Using Locks

do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);

Operating System Concepts – 8th Edition 16 Silberschatz, Galvin and Gagne ©2009

 TestAndSet Instruction

‣ Definition

boolean TestAndSet(boolean *target

boolean rv = *target
*target = TRUE
return rv
}

Operating System Concepts – 8th Edition 17 Silberschatz, Galvin and Gagne ©2009

Solution using TestAndSet

‣ Shared boolean variable lock, initialized to FALS
‣ Solution

do
while ( TestAndSet(&lock )
; // do nothin
// critical sectio
lock = FALSE
// remainder section
} while (TRUE);

Operating System Concepts – 8th Edition 18 Silberschatz, Galvin and Gagne ©2009
{

 Swap Instruction

‣ Definition

void Swap (boolean *a, boolean *b

boolean temp = *a
*a = *b
*b = temp
}

Operating System Concepts – 8th Edition 19 Silberschatz, Galvin and Gagne ©2009

Solution using Swap

‣ Shared Boolean variable lock initialized to FALSE; Each

process has a local Boolean variable key
‣ Solution
do
key = TRUE
while ( key == TRUE
Swap (&lock, &key )
// critical sectio
lock = FALSE
// remainder section
} while (TRUE);

Operating System Concepts – 8th Edition 20 Silberschatz, Galvin and Gagne ©2009
{

 Bounded-waiting Mutual Exclusion

with TestandSet()
do {
Common data structures,
waiting[i] = TRUE;
initialized to FALSE:
key = TRUE;
boolean waiting[n]; while (waiting[i] && key)
boolean lock; key = TestAndSet(&lock);
waiting[i] = FALSE;
// critical section
j = (i + 1) % n;
while ((j != i) && !waiting[j])
j = (j + 1) % n;
if (j == i)
lock = FALSE;
else
waiting[j] = FALSE;
// remainder section
} while (TRUE);

Operating System Concepts – 8th Edition 21 Silberschatz, Galvin and Gagne ©2009

Mutex Locks
‣ Previous solutions are complicated and generally inaccessible
to application programmers

‣ OS designers build software tools to solve critical section

proble
‣ Simplest is mutex lock
‣ Protect a critical section by first acquire() a lock then
release() the lock
✦ Boolean variable indicating if lock is available or no
‣ Calls to acquire() and release() must be atomi
✦ Usually implemented via hardware atomic instruction
‣ But this solution requires busy waitin
✦ This lock therefore called a spinlock

Operating System Concepts – 8th Edition 22 Silberschatz, Galvin and Gagne ©2009

 acquire() and release()

! acquire() {
while (!available)
; /* busy wait */
available = false;;
}
! release() {
available = true;
}
! do {
acquire lock
critical section
release lock
remainder section
} while (true);

Operating System Concepts – 8th Edition 23 Silberschatz, Galvin and Gagne ©2009

Semaphore
‣ Synchronization tool that provides more sophisticated ways (than
Mutex locks) for process to synchronize their activities
‣ Semaphore S – integer variabl
‣ Can only be accessed via two indivisible (atomic) operations : wait()
and signal(
✦ Originally called P() and V()

‣ Definitions of two operations

✦ wait (S) { ✦ signal (S) {
while S <= S++
; // no-op (busy wait }
S—
}

Operating System Concepts – 8th Edition 24 Silberschatz, Galvin and Gagne ©2009

 Semaphore Usage
‣ Counting semaphore – integer value can range over an unrestricted domai
‣ Binary semaphore – integer value can range only between 0 and
✦ Same as a mutex locks
‣ Can implement a counting semaphore S as a binary semaphor
‣ Can solve various synchronization problems (general synchronization tool)
‣ Provides mutual exclusio
Semaphore mutex; // initialized to
do ✦ wait (S) {
while S <=
wait (mutex) ; // no-o
// Critical Sectio S--
signal (mutex)
✦ signal (S) {
// remainder sectio S++
} while (TRUE); }

Operating System Concepts – 8th Edition 25 Silberschatz, Galvin and Gagne ©2009

Semaphore Implementation
‣ Must guarantee that no two processes can execute wait ()
and signal () on the same semaphore at the same tim
‣ Thus, implementation becomes the critical section problem
where the wait and signal code are placed in the critical
sectio
✦ Could now have busy waiting in critical section
implementatio
! But implementation code is shor
! Little busy waiting if critical section rarely occupie

‣ Note that applications may spend lots of time in critical

sections and therefore this is not a good solution

Operating System Concepts – 8th Edition 26 Silberschatz, Galvin and Gagne ©2009
}

 Semaphore Implementation
with no Busy waiting

‣ With each semaphore there is an associated waiting queu

‣ Each entry in a waiting queue has two data items
✦ value (of type integer
✦ pointer to next record in the lis

‣ Two operations
✦ block – place the process invoking the operation on the
appropriate waiting queu
✦ wakeup – remove one of processes in the waiting
queue and place it in the ready queu

Operating System Concepts – 8th Edition 27 Silberschatz, Galvin and Gagne ©2009

Semaphore Implementation with

no Busy waiting (Cont.)
‣ Semaphore definition ‣ Implementation of wait
wait(semaphore *S) {
typedef struct
int value; S->value--;
struct process *L; if (S->value < 0) {
} semaphore; add this process to S->list;
block();
}

‣ Implementation of signal
signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);

Operating System Concepts – 8th Edition 28 Silberschatz, Galvin and Gagne ©2009
}

 Deadlock and Starvation

‣ Deadlock – two or more processes are waiting indefinitely for an event
that can be caused by only one of the waiting processe
‣ Let S and Q be two semaphores initialized to
P0 P
wait (S); wait (Q)
wait (Q); wait (S)
.
.
.

signal (S); signal (Q)

signal (Q); signal (S)
‣ Starvation – indefinite blocking
✦ A process may never be removed from the semaphore queue in
which it is suspende
‣ Priority Inversion – Scheduling problem when lower-priority process
holds a lock needed by higher-priority proces
✦ Solved via priority-inheritance protocol

Operating System Concepts – 8th Edition 29 Silberschatz, Galvin and Gagne ©2009

Classical Problems of Synchronization

‣ Classical problems used to test newly-proposed

synchronization scheme

✦ Bounded-Buffer Proble

✦ Readers and Writers Proble

✦ Dining-Philosophers Problem

Operating System Concepts – 8th Edition 30 Silberschatz, Galvin and Gagne ©2009







d

 Bounded-Buffer Problem

‣ n buffers, each can hold one ite

‣ Semaphore mutex initialized to the value

‣ Semaphore full initialized to the value

‣ Semaphore empty initialized to the value N

Operating System Concepts – 8th Edition 31 Silberschatz, Galvin and Gagne ©2009

Bounded Buffer Problem (Cont.)

‣ The structure of the producer proces
do {
…
// produce an item in next produce
…
wait (empty)
wait (mutex)
…

// add the item to the buffe

…

signal (mutex)
signal (full)
} while (TRUE);

Operating System Concepts – 8th Edition 32 Silberschatz, Galvin and Gagne ©2009

 Bounded Buffer Problem (Cont.)

‣ The structure of the consumer proces
do
wait (full)
wait (mutex)
…

// remove an item from buffer to next consumed

…

signal (mutex)
signal (empty)
…
// consume the item in next consumed
…
} while (TRUE);

Operating System Concepts – 8th Edition 33 Silberschatz, Galvin and Gagne ©2009

Readers-Writers Problem
‣ A data set is shared among a number of concurrent processe
✦ Readers – only read the data set; they do not perform any update
✦ Writers – can both read and write

‣ Problem – allow multiple readers to read at the same tim

✦ Only one single writer can access the shared data at the same tim

‣ Several variations of how readers and writers are considered – all

involve some form of priorities

‣ Shared Dat
✦ Data se
✦ Semaphore mutex initialized to
✦ Semaphore wrt initialized to
✦ Integer readcount initialized to 0

Operating System Concepts – 8th Edition 34 Silberschatz, Galvin and Gagne ©2009
{

 Readers-Writers Problem (Cont.)

‣ The structure of a writer proces

do
wait (wrt)
…
// writing is performe
…
signal (wrt)
} while (TRUE);

Operating System Concepts – 8th Edition 35 Silberschatz, Galvin and Gagne ©2009

Readers-Writers Problem (Cont.)

‣ The structure of a reader proces
do
wait (mutex)
readcount ++
if (readcount == 1)
wait (wrt)
signal (mutex
…
// reading is performed
…
wait (mutex)
readcount - -
if (readcount == 0)
signal (wrt)
signal (mutex)
} while (TRUE);

Operating System Concepts – 8th Edition 36 Silberschatz, Galvin and Gagne ©2009

 Readers-Writers Problem Variations

‣ First variation – no reader kept waiting unless writer has

permission to use shared objec

‣ Second variation – once writer is ready, it performs write asa

‣ Both may have starvation leading to even more variation

‣ Problem is solved on some systems by kernel providing reader-

writer locks

Operating System Concepts – 8th Edition 37 Silberschatz, Galvin and Gagne ©2009

Dining-Philosophers Problem
‣ Philosophers spend their lives thinking
and eatin
‣ Don’t interact with their neighbors,
occasionally try to pick up 2 chopsticks
(one at a time) to eat from bow
✦ Need both to eat, then release both
when don
‣ In the case of 5 philosopher
✦ Shared data
! Bowl of rice (data set)
! Semaphore chopstick [5] initialized to 1

Operating System Concepts – 8th Edition 38 Silberschatz, Galvin and Gagne ©2009
g

 Dining-Philosophers Algorithm
‣ The structure of Philosopher i
do {
wait ( chopstick[i] )
wait ( chopstick[ (i + 1) % 5] )
// ea
signal ( chopstick[i] )
signal (chopstick[ (i + 1) % 5] )
// thin
} while (TRUE)
‣ What is the problem with this algorithm?

Operating System Concepts – 8th Edition 39 Silberschatz, Galvin and Gagne ©2009

Dining-Philosophers Problem Algorithm

‣ Deadlock handlin
✦ Allow at most 4 philosophers to be sitting simultaneously at the
table
✦ Allow a philosopher to pick up the chopsticks only if both are
available (picking must be done in a critical section)
✦ Use an asymmetric solution -- an odd-numbered philosopher
picks up first the left chopstick and then the right chopstick. Even-
numbered philosopher picks up first the right chopstick and then
the left chopstick.

Operating System Concepts – 8th Edition 40 Silberschatz, Galvin and Gagne ©2009
.

 Problems with Semaphores

‣ Incorrect use of semaphore operations:

✦ signal (mutex) …. wait (mutex)

✦ wait (mutex) … wait (mutex

✦ Omitting of wait (mutex) or signal (mutex) (or both

‣ Deadlock and starvation are possible.

Operating System Concepts – 8th Edition 41 Silberschatz, Galvin and Gagne ©2009

Monitors
‣ A high-level abstraction that provides a convenient and
effective mechanism for process synchronizatio
‣ Abstract data type, internal variables only accessible by code
within the procedur
‣ Only one process may be active within the monitor at a tim
monitor monitor-nam

// shared variable declaration

procedure P1 (…) { ….
procedure Pn (…) {……
Initialization code (…) { …

}
Operating System Concepts – 8th Edition 42 Silberschatz, Galvin and Gagne ©2009
{

 Schematic view of a Monitor

Operating System Concepts – 8th Edition 43 Silberschatz, Galvin and Gagne ©2009

Condition Variables

‣ Not powerful enough to model some synchronization

schemes => condition variables
‣ condition x, y
‣ Two operations on a condition variable
✦ x.wait () – a process that invokes the operation is
suspended until x.signal ()
✦ x.signal () – resumes one of processes (if any) that
invoked x.wait (
! If no x.wait () on the variable, then it has no effect on
the variable

Operating System Concepts – 8th Edition 44 Silberschatz, Galvin and Gagne ©2009
;

 Monitor with Condition Variables

Operating System Concepts – 8th Edition 45 Silberschatz, Galvin and Gagne ©2009

Condition Variables Choices

‣ If process P invokes x.signal (), and process Q is suspended in x.wait (),
what should happen next
✦ Both Q and P cannot execute in paralel. If Q is resumed, then P
must wai

‣ Options includ
✦ Signal and wait – P waits until Q either leaves the monitor or it waits
for another condition
✦ Signal and continue – Q waits until P either leaves the monitor or it
waits for another condition
✦ Both have pros and cons – language implementer can decid
✦ Monitors implemented in Concurrent Pascal compromis
! P executing signal immediately leaves the monitor, Q is resume
✦ Implemented in other languages including Mesa, C#, Java

Operating System Concepts – 8th Edition 46 Silberschatz, Galvin and Gagne ©2009
t

 Monitor Solution to Dining Philosophers

monitor DiningPhilosopher
{
enum {THINKING, HUNGRY, EATING} state [5]
condition self [5]
void pickup (int i) {
state[i] = HUNGRY
test(i)
if (state[i] != EATING) self [i].wait

void putdown (int i) {

state[i] = THINKING
// test left and right neighbor
test((i + 4) % 5)
test((i + 1) % 5)
}
Operating System Concepts – 8th Edition 47 Silberschatz, Galvin and Gagne ©2009

Monitor Solution to Dining Philosophers (Cont.)

void test (int i) {
if ( (state[(i + 4) % 5] != EATING) &
(state[i] == HUNGRY) &
(state[(i + 1) % 5] != EATING) ) {
state[i] = EATING
self[i].signal ()

initialization_code() {
for (int i = 0; i < 5; i++
state[i] = THINKING

Operating System Concepts – 8th Edition 48 Silberschatz, Galvin and Gagne ©2009

&

&

 Monitor Solution to Dining Philosophers (Cont.)

‣ Each philosopher i invokes the operations pickup() and
putdown() in the following sequence

DiningPhilosophers.pickup (i)

EA

DiningPhilosophers.putdown (i)

‣ No deadlock, but starvation is possibl

Operating System Concepts – 8th Edition 49 Silberschatz, Galvin and Gagne ©2009

Monitor Implementation Using Semaphores

‣ Variables
semaphore mutex; // (initially = 1
semaphore next; // (initially = 0
int next_count = 0;
‣ Each procedure F will be replaced b
wait(mutex)

body of F

if (next_count > 0
signal(next
else
signal(mutex);

‣ Mutual exclusion within a monitor is ensured

Operating System Concepts – 8th Edition 50 Silberschatz, Galvin and Gagne ©2009

…
…

 Monitor Implementation – Condition Variables

‣ For each condition variable x, we have

semaphore x_sem; // (initially = 0
int x_count = 0;
‣ The operation x.wait can be implemented as
x_count++
if (next_count > 0
signal(next)
els
signal(mutex)
wait(x_sem)
x_count--;

Operating System Concepts – 8th Edition 51 Silberschatz, Galvin and Gagne ©2009

Monitor Implementation (Cont.)

‣ The operation x.signal can be implemented as:

if (x_count > 0)
next_count++
signal(x_sem)
wait(next)
next_count--

Operating System Concepts – 8th Edition 52 Silberschatz, Galvin and Gagne ©2009
}

 Resuming Processes within a Monitor

‣ If several processes queued on condition x, and x.signal()

executed, which should be resumed

‣ FCFS frequently not adequate

‣ conditional-wait construct of the form x.wait(c

✦ Where c is priority numbe
✦ Process with lowest number (highest priority) is scheduled
next

Operating System Concepts – 8th Edition 53 Silberschatz, Galvin and Gagne ©2009

A Monitor to Allocate Single Resource

Allocate a single resource monitor ResourceAllocator
‣
among competing processes {
using priority numbers that boolean busy;
condition x;
specify the maximum time a
void acquire(int time) {
process plans to use the
if (busy)
resource:
x.wait(time);
R.acquire(t); busy = TRUE;
}
...
void release() {
access the resource;
busy = FALSE;
...
x.signal();
R.release(); }
initialization code()
‣ Where R is an instance of type busy = FALSE;
ResourceAllocator
}
Operating System Concepts – 8th Edition 54 Silberschatz, Galvin and Gagne ©2009

 Synchronization Examples

‣ Solari

‣ Windows X

‣ Linu

‣ Pthreads

Operating System Concepts – 8th Edition 55 Silberschatz, Galvin and Gagne ©2009

Solaris Synchronization
‣ Implements a variety of locks to support multitasking, multithreading (including
real-time threads), and multiprocessin

‣ Uses adaptive mutexes for efficiency when protecting data from short code
segment
✦ Starts as a standard semaphore spin-loc
✦ If lock held, and by a thread running on another CPU, spin
✦ If lock held by non-run-state thread, block and sleep waiting for signal of lock
being release

‣ Uses condition variables

‣ Uses readers-writers locks to protect data that are accessed frequently but are
usually accessed in a read-only manner.
‣ Uses turnstiles to order the list of threads waiting to acquire either an adaptive
mutex or reader-writer loc
✦ Turnstiles are per-lock-holding-thread, not per-objec

‣ Priority-inheritance per-turnstile gives the running thread the highest of the

priorities of the threads in its turnstile

Operating System Concepts – 8th Edition 56 Silberschatz, Galvin and Gagne ©2009
x

 Windows XP Synchronization
‣ Uses interrupt masks to protect access to global resources on
uniprocessor system

‣ Uses spinlocks on multiprocessor system

✦ Spinlocking-thread will never be preempte

‣ Also provides dispatcher objects user-land which may act

mutexes, semaphores, events, and timer
✦ Event
! An event acts much like a condition variabl
✦ Timers notify one or more thread when time expire
✦ Dispatcher objects either signaled-state (object available)
or non-signaled state (thread will block)

Operating System Concepts – 8th Edition 57 Silberschatz, Galvin and Gagne ©2009

Linux Synchronization
‣ Linux
✦ Prior to kernel Version 2.6, disables interrupts to
implement short critical section
✦ Version 2.6 and later, fully preemptiv

‣ Linux provides
✦ semaphore
✦ spinlock
✦ reader-writer versions of bot

‣ On single-cpu system, spinlocks replaced by enabling and

disabling kernel preemption

Operating System Concepts – 8th Edition 58 Silberschatz, Galvin and Gagne ©2009
:

 Pthreads Synchronization
‣ Pthreads API is OS-independen

‣ It provides
✦ mutex lock
✦ condition variables

‣ Non-portable extensions include

✦ read-write lock
✦ spinlocks

Operating System Concepts – 8th Edition 59 Silberschatz, Galvin and Gagne ©2009

End of Chapter 3

Operating System Concepts – 8th Edition Silberschatz, Galvin and Gagne ©2009
: