Chapter 6: Process

Synchronization Tools

Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013
 Chapter 6: Process Synchronization
 Background
 The Critical-Section Problem
 Peterson’s Solution
 Synchronization Hardware
 Mutex Locks
 Semaphores

Operating System Concepts – 9th Edition 5.2 Silberschatz, Galvin and Gagne ©2013
 Objectives
 To present the concept of process synchronization.
 To introduce the critical-section problem, whose solutions
can be used to ensure the consistency of shared data
 To present both software and hardware solutions of the
critical-section problem
 To examine several classical process-synchronization
problems

Operating System Concepts – 9th Edition 5.3 Silberschatz, Galvin and Gagne ©2013
 Background
 Processes can execute concurrently
 May be interrupted at any time, partially completing execution
 Concurrent access to shared data may result in data inconsistency
 Maintaining data consistency requires mechanisms to ensure the
orderly execution of cooperating processes
 Illustration of the problem:

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 – 9th Edition 5.4 Silberschatz, Galvin and Gagne ©2013
 Producer

while (true) {
/* produce an item in next produced */

while (counter == BUFFER_SIZE) ;

/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}

Operating System Concepts – 9th Edition 5.5 Silberschatz, Galvin and Gagne ©2013
 Consumer

while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */
}

Operating System Concepts – 9th Edition 5.6 Silberschatz, Galvin and Gagne ©2013
 Race Condition
 counter++ could be implemented as
register1 = counter
register1 = register1 + 1
counter = register1
 counter-- could be implemented as
register2 = counter
register2 = register2 - 1
counter = register2

 Consider this execution interleaving with “count = 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}

Operating System Concepts – 9th Edition 5.7 Silberschatz, Galvin and Gagne ©2013
 Critical Section Problem
 Consider system of n processes {p0, p1, … pn-1}
 Each process has critical section segment of code
 Process may be changing common variables, updating
table, writing file, etc
 When one process in critical section, no other may be in its
critical section
 Critical section problem is to design protocol to solve this
 Each process must ask permission to enter critical section in
entry section, may follow critical section with exit section,
then remainder section

Operating System Concepts – 9th Edition 5.8 Silberschatz, Galvin and Gagne ©2013
 Critical Section

 General structure of process Pi

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

section

Operating System Concepts – 9th Edition 5.9 Silberschatz, Galvin and Gagne ©2013
 Algorithm for Process Pi, Pj
do {

while (turn == j);

critical section
turn = j;

remainder section
} while (true);

do {

while (turn == i);

critical section
turn = i;

remainder section
} while (true);

Operating System Concepts – 9th Edition 5.10 Silberschatz, Galvin and Gagne ©2013
 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 sections
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 indefinitely
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
 Assume that each process executes at a nonzero speed
 No assumption concerning relative speed of the n
processes

Operating System Concepts – 9th Edition 5.11 Silberschatz, Galvin and Gagne ©2013
 Peterson’s Solution
 Good algorithmic description of solving the problem
 Two process solution
 Assume that the load and store machine-language
instructions are atomic; that is, cannot be interrupted
 The two processes share two variables:
 int turn;
 Boolean flag[2]

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

section
 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 – 9th Edition 5.13 Silberschatz, Galvin and Gagne ©2013
 Algorithm for Process Pi

do {
flag[i] = true;
turn = j;
while (flag[j] && turn = = j);
critical section
flag[i] = false;
remainder section
} while (true);

Operating System Concepts – 9th Edition 5.14 Silberschatz, Galvin and Gagne ©2013
 Algorithm for Process Pj

do {
flag[j] = true;
turn = i;
while (flag[i] && turn = = i);
critical section
flag[j] = false;
remainder section
} while (true);

Operating System Concepts – 9th Edition 5.15 Silberschatz, Galvin and Gagne ©2013
 Peterson’s Solution (Cont.)
 Provable that the three CS requirement are met:
1. Mutual exclusion is preserved
Pi enters CS only if:
either flag[j] = false or turn = i
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met

Operating System Concepts – 9th Edition 5.16 Silberschatz, Galvin and Gagne ©2013
 Solution using compare_and_swap
 Shared integer “lock” initialized to 0;
 Solution:
do {
while (compare_and_swap(&lock, 0, 1) != 0)
; /* do nothing */
/* critical section */
lock = 0;
/* remainder section */
} while (true);

Operating System Concepts – 9th Edition 5.22 Silberschatz, Galvin and Gagne ©2013
 Mutex Locks
 Previous solutions are complicated and generally inaccessible to
application programmers
 OS designers build software tools to solve critical section problem
 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 not
 Calls to acquire() and release() must be atomic
 Usually implemented via hardware atomic instructions
 But this solution requires busy waiting
 This lock therefore called a spinlock

Operating System Concepts – 9th Edition 5.24 Silberschatz, Galvin and Gagne ©2013
 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 – 9th Edition 5.25 Silberschatz, Galvin and Gagne ©2013
  This continual looping is clearly a problem in a real multiprogramming
system, where a single CPU is shared among many processes.
 Busy waiting wastes CPU cycles that some other process might be

able to use productively.

 Spinlocks do have an advantage, however, in that no context switch is

required when a process must wait on a lock, and a context switch may
take considerable time.
 They are often employed on multiprocessor systems where one thread
can “spin” on one processor while another thread performs its critical
section on another processor.

Operating System Concepts – 9th Edition 5.26 Silberschatz, Galvin and Gagne ©2013
 Semaphore

 A more robust tool that can behave similarly to a mutex

locks.
 Synchronization tool that provides more sophisticated ways
(than Mutex locks) for process to synchronize their
activities.
 Semaphore S – integer variable
 Can only be accessed via two indivisible (atomic)
operations
 wait() and signal()
 Originally called P() and V()
 Dutch proberen, “to test”); signal() was originally called V
(from verhogen, “to increment

Operating System Concepts – 9th Edition 5.27 Silberschatz, Galvin and Gagne ©2013
  Definition of the wait() operation
wait(S) {
while (S <= 0)
; // busy wait
S--;
}
 Definition of the signal() operation
signal(S) {
S++;
}

Operating System Concepts – 9th Edition 5.28 Silberschatz, Galvin and Gagne ©2013
  All modifications to the integer value of the semaphore in the
wait() and signal() operations must be executed indivisibly.
 when one process modifies the semaphore value, no other
process can simultaneously modify that same semaphore value.
 wait(S), the testing of the integer value of S (S ≤ 0), as well as
its possible modification (S--), must be executed without
interruption.

Operating System Concepts – 9th Edition 5.29 Silberschatz, Galvin and Gagne ©2013
 Semaphore Usage
 Counting semaphore – integer value can range over an
unrestricted domain
 Binary semaphore – integer value can range only between 0 and 1
 Same as a mutex lock
 In fact, on systems that do not provide mutex locks, binary
semaphores can be used instead for providing mutual
exclusion.

Operating System Concepts – 9th Edition 5.30 Silberschatz, Galvin and Gagne ©2013
 Semaphore Usage
 Counting semaphore – integer value can range over an
unrestricted domain
 Counting semaphores can be used to control access to a
given resource consisting of a finite number of instances.
 The semaphore is initialized to the number of resources
available.
 Each process that wishes to use a resource performs a
wait() operation on the semaphore (There by decrementing
the count).

Operating System Concepts – 9th Edition 5.31 Silberschatz, Galvin and Gagne ©2013
  When a process releases a resource, it performs a
signal() operation (incrementing the count).

 When the count for the semaphore goes to 0, all

resources are being used.

 After that, processes that wish to use a resource will

block until the count becomes greater than 0.

Operating System Concepts – 9th Edition 5.32 Silberschatz, Galvin and Gagne ©2013
  Can be used to solve various synchronization problems
 Consider P1 and P2 that require S1 to happen before S2

Create a semaphore “synch” initialized to 0

P1:
S1;
signal(synch);
P2:
wait(synch);
S2;
 Can implement a counting semaphore S as a binary
semaphore
Operating System Concepts – 9th Edition 5.33 Silberschatz, Galvin and Gagne ©2013
 Semaphore Implementation
 Must guarantee that no two processes can execute the wait()
and signal() on the same semaphore at the same time.
 Thus, the implementation becomes the critical section problem where
the wait and signal code are placed in the critical section
 Could now have busy waiting in critical section implementation
 But implementation code is short
 Little busy waiting if critical section rarely occupied
 Note that applications may spend lots of time in critical sections and
therefore this is not a good solution

Operating System Concepts – 9th Edition 5.34 Silberschatz, Galvin and Gagne ©2013
 Semaphore Implementation with no Busy waiting

 With each semaphore there is an associated waiting queue

 Each entry in a waiting queue has two data items:
 value (of type integer)
 pointer to next record in the list
 Two operations:
 block – place the process invoking the operation on the appropriate
waiting queue
 wakeup – remove one of processes in the waiting queue and place it
in the ready queue

 typedef struct{
int value;
struct process *list;
} semaphore;

Operating System Concepts – 9th Edition 5.35 Silberschatz, Galvin and Gagne ©2013
 Implementation with no Busy waiting (Cont.)

wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}

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

Operating System Concepts – 9th Edition 5.36 Silberschatz, Galvin and Gagne ©2013
 Classical Problems of Synchronization
 Classical problems used to test newly-proposed synchronization
schemes
 Bounded-Buffer Problem
 Readers and Writers Problem
 Dining-Philosophers Problem

Operating System Concepts – 9th Edition 5.38 Silberschatz, Galvin and Gagne ©2013
 Bounded-Buffer Problem

 n buffers, each can hold one item

 Semaphore mutex initialized to the value 1
 Semaphore full initialized to the value 0
 Semaphore empty initialized to the value n

Operating System Concepts – 9th Edition 5.39 Silberschatz, Galvin and Gagne ©2013
 Bounded Buffer Problem (Cont.)
 The structure of the producer process

do {
...
/* produce an item in next_produced */
...
wait(empty);
wait(mutex);
...
/* add next produced to the buffer */
...
signal(mutex);
signal(full);
} while (true);

Operating System Concepts – 9th Edition 5.40 Silberschatz, Galvin and Gagne ©2013
 Bounded Buffer Problem (Cont.)
 The structure of the consumer process
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 – 9th Edition 5.41 Silberschatz, Galvin and Gagne ©2013
 Readers-Writers Problem
 A data set is shared among a number of concurrent processes
 Readers – only read the data set; they do not perform any updates
 Writers – can both read and write
 Problem – allow multiple readers to read at the same time
 Only one single writer can access the shared data at the same time
 Several variations of how readers and writers are considered – all
involve some form of priorities.
 Shared Data
 Data set
 Semaphore rw_mutex initialized to 1
 Semaphore mutex initialized to 1
 Integer read_count initialized to 0

Operating System Concepts – 9th Edition 5.42 Silberschatz, Galvin and Gagne ©2013
 Readers-Writers Problem (Cont.)

 The structure of a writer process

do {
wait(rw_mutex);
...
/* writing is performed */
...
signal(rw_mutex);
} while (true);

Operating System Concepts – 9th Edition 5.43 Silberschatz, Galvin and Gagne ©2013
 Readers-Writers Problem (Cont.)
 The structure of a reader process
do {
wait(mutex);
read_count++;
if (read_count == 1)
wait(rw_mutex);
signal(mutex);
...
/* reading is performed */
...
wait(mutex);
read count--;
if (read_count == 0)
signal(rw_mutex);
signal(mutex);
} while (true);

Operating System Concepts – 9th Edition 5.44 Silberschatz, Galvin and Gagne ©2013
 Readers-Writers Problem Variations
 First variation – no reader kept waiting unless writer has
permission to use shared object
 Second variation – once writer is ready, it performs the
write ASAP
 Both may have starvation leading to even more variations
 Problem is solved on some systems by kernel providing
reader-writer locks

Operating System Concepts – 9th Edition 5.45 Silberschatz, Galvin and Gagne ©2013
 Dining-Philosophers Problem

Operating System Concepts – 9th Edition 5.46 Silberschatz, Galvin and Gagne ©2013
  Philosophers spend their lives alternating thinking and
eating.
 The philosophers share a circular table surrounded by
five chairs, each belonging to one philosopher.
 Don’t interact with their neighbors, occasionally try to
pick up 2 chopsticks (one at a time) to eat from bowl.
 Need both to eat, then release both when done
 In the case of 5 philosophers
 Shared data
 Bowl of rice (data set)
 Semaphore chopstick [5] initialized to 1

Operating System Concepts – 9th Edition 5.47 Silberschatz, Galvin and Gagne ©2013
  It is an example of a large class of concurrency-
control problems.

 It is a simple representation of the need to allocate

several resources among several processes in a
deadlock-free And starvation-free manner

 Represent each chopstick with a semaphore.

Operating System Concepts – 9th Edition 5.48 Silberschatz, Galvin and Gagne ©2013
 Dining-Philosophers Problem Algorithm
 The structure of Philosopher i:
do {
wait (chopstick[i] );
wait (chopStick[ (i + 1) % 5] );

// eat

signal (chopstick[i] );
signal (chopstick[ (i + 1) % 5] );

// think

} while (TRUE);
 What is the problem with this algorithm?

Operating System Concepts – 9th Edition 5.49 Silberschatz, Galvin and Gagne ©2013
  This solution guarantees that no two neighbors are eating
simultaneously,
 it nevertheless must be rejected because it could create
a deadlock.

 Suppose that all five philosophers become hungry at the same

time and each grabs her left chopstick.
 All the elements of chopstick will now be equal to 0.

 When each philosopher tries to grab her right chopstick, she will
be delayed forever.

Operating System Concepts – 9th Edition 5.50 Silberschatz, Galvin and Gagne ©2013
 Several possible remedies to the deadlock problem are replaced by:

Allow at most four philosophers to be sitting simultaneously at the table.

Allow a philosopher to pick up her chopsticks only if both chopsticks are
available (to do this, she must pick them up in a critical section)

 Use an asymmetric solution—that is, an odd-numbered philosopher

picks up first her left chopstick and then her right chopstick, whereas
an even- numbered philosopher picks up her right chopstick and then
her left chopstick.

Operating System Concepts – 9th Edition 5.51 Silberschatz, Galvin and Gagne ©2013
 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 – 9th Edition 5.52 Silberschatz, Galvin and Gagne ©2013