Process

Synchronization

Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013
  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
Objectives hardware solutions of the
critical-section problem
 To examine several classical
process-synchronization
problems
 To explore several tools that are
used to solve process
synchronization problems

Operating System Concepts – 9th Edition 5.2 Silberschatz, Galvin and Gagne ©2013
 Background

 A cooperating process is one that can affect or be affected by other

processes executing in the system.
 Cooperating processes can directly share a logical address space (both
code and data).
 Concurrent access to shared data may result in data inconsistency
 Various mechanisms are available to ensure the orderly execution of
cooperating processes that share a logical address space, so that data
consistency is maintained.

What other way can cooperating processes

communicate that would eliminate this issue?
Operating System Concepts – 9th Edition 5.3 Silberschatz, Galvin and Gagne ©2013
 Consumer-Producer Problem
Alternate Solution

 Suppose that we wanted to provide a solution to the

consumer-producer problem that removes the restriction
of having at most BUFFER_SIZE-1 items.
 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
 Let's Go Behind the Curtain

Operating System Concepts – 9th Edition 5.7 Silberschatz, Galvin and Gagne ©2013
 counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
counter-- could be implemented as

register2 = counter
register2 = register2 - 1
counter = register2
What Can Consider this execution interleaving with “counter = 5” initially:
Possibly Go 1. S0: producer executes register1 = counter
{register1 = 5}

Wrong? 2. S1: producer executes register1 = register1 + 1

{register1 = 6}
3. S2: consumer executes register2 = counter
{register2 = 5}
4. S3: consumer executes register2 = register2 – 1
{register2 = 4}
5. S4: producer executes counter = register1
{counter = 6}
6. S5: consumer executes counter = register2
{counter = 4}

Operating System Concepts – 9th Edition 5.8 Silberschatz, Galvin and Gagne ©2013
 What Can Possibly Go Wrong?

If we reverse S4 and S5? - we get Counter=6!

 Consider this execution interleaving with “counter = 5” initially:

 S0: producer executes register1 = counter {register1 = 5}
 S1: producer executes register1 = register1 + 1 {register1 = 6}
 S2: consumer executes register2 = counter {register2 = 5}
 S3: consumer executes register2 = register2 – 1 {register2 = 4}
 S4: consumer executes counter = register2 {counter = 4}
 S5: producer executes counter = register1 {counter = 6}

Operating System Concepts – 9th Edition 5.9 Silberschatz, Galvin and Gagne ©2013
  A situation where several
processes access and
manipulate the same data

What’s
concurrently and the
outcome of the execution
depends on the order in
which the access takes
place.

the
 We need a way to
synchronize the
processes so that only
one process at a time can
be manipulating a critical

problem?
data item.
Race Condition

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

 Consider system of n processes {p , p , … p }

0 1 n-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 a protocol to support this
 Each process
 must ask permission to enter critical section in entry section
 may follow critical section with exit section
 The remaining code is the remainder section

Operating System Concepts – 9th Edition 5.11 Silberschatz, Galvin and Gagne ©2013
 General structure of process Pi
Critical
Section
Process
Structure

Operating System Concepts – 9th Edition 5.12 Silberschatz, Galvin and Gagne ©2013
 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 some processes wish to
enter their critical sections,
 only those processes that are not executing
in their remainder sections can participate in
Solution to deciding which will enter its critical section
next, and
Critical-  this selection cannot be postponed
indefinitely
Section 3. Bounded Waiting - A bound must exist on
the number of times that other processes are
Problem 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
5.13
n processes Silberschatz, Galvin and Gagne ©2013
Operating System Concepts – 9th Edition
  Kernel Open Files data structure
 List must be modified when a new file is
opened or closed
 If two processes were to open files
Areas simultaneously, the separate updates to
this file could cause a race condition
Prone to
 Memory Allocation Structures
Race  Process List Structures
Conditions  Interrupt Handling

Operating System Concepts – 9th Edition 5.14 Silberschatz, Galvin and Gagne ©2013
  Non-preemptive – runs until exits kernel
mode, blocks, or voluntarily yields CPU
 Essentially free of race conditions in kernel
mode
 Preemptive – allows preemption of process
when running in kernel mode
Critical-  Are hard to design especially in SMP
(Symmetric Multiprocessors) architectures
Section where two kernel-mode processes can be
running simultaneously on different
Handling in processors.
Why choose preemptive?
OSs  More responsive since risk of long-running
processes holding up the works is eliminated
 More suitable for real-time programming as
real-time processes can preempt as needed.

Operating System Concepts – 9th Edition 5.15 Silberschatz, Galvin and Gagne ©2013
 Synchronization Hardware
 Many systems provide hardware support for
implementing the critical section code.
 All solutions below based on idea of locking
 Protecting critical regions via locks
 Uniprocessors – could disable interrupts
 Currently running code would execute without
preemption
 This is the approach generally taken for non-
preemptive kernels
 Generally too inefficient on multiprocessor
systems.
 Why?
 Message is passed to all processors
 This delays entry into each critical section
decreasing system efficiency
 May impact clock performance if clock is
updated using interrupts
Operating System Concepts – 9th Edition 5.16 Silberschatz, Galvin and Gagne ©2013
 Synchronization
Hardware

 Modern machines provide special

atomic hardware instructions
Atomic = non-interruptible
 test and modify contents of
memory word
 swap contents of two memory
words
 These instructions can be used to
solve the critical section problem.

Operating System Concepts – 9th Edition 5.17 Silberschatz, Galvin and Gagne ©2013
 Mutex Locks

 OS designers build software tools to solve the critical section problem

 Simplest is mutex lock: (mutual exclusion)
 Protect a critical section by first acquire() a lock then
release() the lock
 Boolean variable available indicating if lock is available or
not
 Usually implemented via hardware atomic instructions
do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);
Operating System Concepts – 9th Edition 5.18 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.19 Silberschatz, Galvin and Gagne ©2013
  But this solution requires busy waiting
 When a process is in its critical section, any
other process that tries to enter its critical
section must loop continuously in the calls to
acquire()
 and is therefore called a spinlock because the
process spins while waiting for the lock to
become available.
 In a single CPU multiprogramming environment
Mutex busy waiting wastes CPU cycles that could be
used by other processes.

Locks  But…
 Spinlocks do not require context switching and
are efficient when locks are expected to be held
for short times.
 Multiprocessor systems are good candidates for
spinlocks as another thread can enter its critical
section on another processor.

Operating System Concepts – 9th Edition 5.20 Silberschatz, Galvin and Gagne ©2013
  Synchronization tool that provides more
sophisticated ways (than Mutex locks) for
processes to synchronize their activities.
 Semaphore S – integer variable
 Can only be accessed via two indivisible (atomic)
operations
wait() and signal()
 Definition of the wait() operation
Semaphore wait(S) {
while (S <= 0)
; // busy wait
S--;
}
 Definition of the signal() operation
signal(S) {
S++;
}

Operating System Concepts – 9th Edition 5.21 Silberschatz, Galvin and Gagne ©2013
  Counting Semaphore – integer value can range over an
unrestricted domain
 Used to provide access to a resource consisting of a finite # of
resources
 The semaphore is initialized to the number of available
resources
 Each process that wishes to use a resource performs a wait()
operation the decrements the semaphore
 When a process releases a resource, it performs a signal()
operations that increments the semaphore.
 When the semaphore goes to 0, all resources are being used.
 After that, all processes that wish to use a resource will block
until the count becomes >0.

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

 Binary semaphore – integer value can range only between 0 and 1

Same as a mutex lock (and they suffer from busy-wait too)
 Can 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;
 Because synch is set to 0, P2 will execute S2 only after P1 has
invoked signal (synch) which is after statement S1 has been
executed.
Operating System Concepts – 9 Edition
th 5.23 Silberschatz, Galvin and Gagne ©2013
 Semaphore Implementation

 We can modify the definition of wait() and signal() as

follows:
 When a process executes a wait() operation and finds
that the semaphore value is not positive, it must wait.
 Rather than engaging in busy waiting, the process can
block itself.
 The block operations puts the process into a waiting
queue associated with the semaphore and the state of
the process is switched to ‘waiting’.
 Control is transferred to the CPU scheduler which
selects another process to execute.
 A process that is blocked should be restarted using the
wakeup() operation when some other process executes
a signal() operation.
 This changes the process state to ‘ready’ and it will get
scheduled based on the CPU scheduler’s priority
algorithm

Operating System Concepts – 9th Edition 5.24 Silberschatz, Galvin and Gagne ©2013
  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:
Semaphore  block – place the process invoking the
operation on the appropriate waiting
Implementation queue
with no Busy  wakeup – remove one of processes in
waiting the waiting queue and place it in the
ready queue
 typedef struct{
int value;
struct process *list;
} semaphore;

Operating System Concepts – 9th Edition 5.25 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);
} Semaphore values can be negative.
}
Magnitude = # of processes waiting
5.26
Operating System Concepts – 9th Edition 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

So, are we back to square one?

Operating System Concepts – 9th Edition 5.27 Silberschatz, Galvin and Gagne ©2013
  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
Implementation  But implementation of wait and
with no Busy signal code is short
waiting (Cont.)  Little busy waiting if critical
section rarely occupied
 Busy waiting is more of a
concern in applications that may
spend a long time in their critical
section and therefore this is not
a good solution

Operating System Concepts – 9th Edition 5.28 Silberschatz, Galvin and Gagne ©2013
 2
9

Operating System Concepts – 9th Edition 5.29 Silberschatz, Galvin and Gagne ©2013
 Deadlock

Operating System Concepts – 9th Edition 5.30 Silberschatz, Galvin and Gagne ©2013
 Deadlock and Starvation
 Deadlock – two or more processes are waiting indefinitely for an event that can be
caused by only one of the waiting processes
 Let S and Q be two semaphores initialized to 1
P0 P1
 wait(S); wait(Q);
 wait(Q); wait(S);
 BLOCKED ... BLOCKED ...
 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.
Operating System Concepts – 9th Edition 5.31 Silberschatz, Galvin and Gagne ©2013
 Deadlock and Starvation
Four necessary conditions for deadlock:
1. Mutual Exclusion Condition –
 Resource may be acquired by one and only one process at a
time
2. Wait-For Condition (Hold and Wait Condition)
 Process that has acquired an exclusive resource may hold
that resource while the process waits to obtain other
resources
3. No-preemption Condition
 Once a process has obtained a resource, the system cannot
remove it from the process’ control until the process is
finished using the resource.
4. Circular-Wait Condition
 Two or more processes are locked in a ‘circular chain’ in
which each process is waiting for one or more resources that
the next process in the chain is holding.

Operating System Concepts – 9th Edition 5.32 Silberschatz, Galvin and Gagne ©2013
 Priority Inversion – Scheduling problem
when lower-priority process holds a lock
needed by higher-priority process
 Consider processes L, M, and H whose
priorities are represented by:
L < M < H.
 Assume process H requires resource R
Priority that is currently being accessed by
process L.
Inversion  H would have to wait for L to complete to
access resource R.
BUT…
 M becomes runnable and preempts
process L.
 Now, M, a process with a lower priority
than H, has affected how long H must
wait for L to relinquish resource R.

Operating System Concepts – 9th Edition 5.33 Silberschatz, Galvin and Gagne ©2013
 Priority Inversion - Solved

 Solved via priority-inheritance protocol

 All processes that are accessing resources that are needed
by a higher-priority process inherit the higher priority until
they have finished with the resources in question.
 When they are finished using those resources, their
priorities revert to their original values.

 In our original example:

 When it is detected that L is using a process that H is waiting
for, L will inherit temporarily the H’s high priority.
 This will prevent M, when it becomes runnable, from
preempting its execution and causing H to wait longer.
 When it completes, L reverts to its original priority
 Now that resource R is available, H, with the higher priority
than M, will execute.

Operating System Concepts – 9th Edition 5.34 Silberschatz, Galvin and Gagne ©2013
 Classical Problems of Synchronization

 Classical problems used to test newly-proposed

synchronization schemes
1. Bounded-Buffer Problem
2. Readers and Writers Problem
3. Dining-Philosophers Problem

Operating System Concepts – 9th Edition 5.35 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.36 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.37 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.38 Silberschatz, Galvin and Gagne ©2013
 Readers-Writers Problem

A data set is
shared among Problem – Shared Data
several concurrent 1.Data set
processes Allow multiple
readers to read at 2. Semaphore rw_mutex
Readers – only read initialized to 1
the same time
the data set; they do
not perform any When a writer 3. Semaphore mutex initialized
updates accesses the shared to 1 (protects read_count
data, no reader (or actions)
Writers – can both
writer) may access 4. Integer read_count
read and write
the shared data at initialized to 0 (how many
the same time readers)

Operating System Concepts – 9th Edition 5.39 Silberschatz, Galvin and Gagne ©2013
 The structure of a writer process

do {
wait(rw_mutex);
Readers- ...
/* writing is
Writers performed */
Problem ...
signal(rw_mutex);
(Cont.) } while (true);

Operating System Concepts – 9th Edition 5.40 Silberschatz, Galvin and Gagne ©2013
 Readers-Writers Problem (Cont.)
The structure of a reader process

do {
wait(mutex); lock the read_count variable
read_count++;
if (read_count == 1) for first or last reader
wait(rw_mutex);
signal(mutex); unlock the read_count variable
...
/* reading is performed */
...
wait(mutex); lock the read_count variable
read_count--;
if (read_count == 0)
signal(rw_mutex); for the last reader
signal(mutex); unlock the read_count variable
} while (true);
Operating System Concepts – 9 Edition
th 5.41 Silberschatz, Galvin and Gagne ©2013
 Dining-Philosophers
Problem

 Philosophers spend their lives

alternating thinking and eating
 Occasionally, they try to pick up 2
chopsticks (one at a time, one to the
right and one to the left) to eat from
bowl
 Need both to eat, then release both
when done
 In the case of 5 philosophers and five
chopsticks
 Shared data
 Bowl of rice (data set)
 Semaphore chopstick [5]
initialized to 1

Operating System Concepts – 9th Edition 5.42 Silberschatz, Galvin and Gagne ©2013
  The structure of Philosopher i:
do {
wait (chopstick[i] );
wait (chopStick[ (i + 1) %
5] );

// eat

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

Problem // think
Algorithm
} while (TRUE);

What is the problem with this algorithm?

If they all get hungry at the same time and grab their left chopstick,
when they try to grab their right chopstick they will be delayed forever
= DEADLOCK
Operating System Concepts – 9th Edition 5.43 Silberschatz, Galvin and Gagne ©2013
 Dining-Philosophers Problem Algorithm
Deadlock Handling

Allow at most 4 philosophers to be sitting

Allow simultaneously at the table with five chopsticks
available.

Allow a philosopher to pick up the chopsticks only if

Allow both are available (picking must be done in a critical
section).

Use an asymmetric solution --

An odd-numbered philosopher picks up first the left
Use chopstick and then the right chopstick.
An even-numbered philosopher picks up first the right
chopstick and then the left chopstick.

Operating System Concepts – 9th Edition 5.44 Silberschatz, Galvin and Gagne ©2013
 Transactional Memory
 A memory transaction is a sequence of read-write operations to
memory that are performed atomically.

void update()
{
atomic {
/* modify shared data */
}
}
 Advantages:
 System provides atomicity, not developer
 No locks are involved … so no deadlock.
 Transactional memory system can detect opportunities for
concurrency within an atomic block
 Implementation
 Software Transactional Memory (STM)– code inserted by
compiler to guarantee atomicity and detect concurrency options
 Hardware Transactional Memory (HTM)– Uses cache
hierarchies and cache coherency protocols to manage shared
data conflicts. Less overhead than STM

Operating System Concepts – 9th Edition 5.45 Silberschatz, Galvin and Gagne ©2013
 End

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