Background

 Processes can execute concurrently

• May be interrupted at any time, partially completing execution
Lecture 7: Synchronization  Concurrent access to shared data may result in data
inconsistency
(Semaphores)  Maintaining data consistency requires mechanisms to ensure the
orderly execution of cooperating processes
 We illustrated in chapter 4 the problem when we considered the
Bounded Buffer problem with use of a counter that is updated
concurrently by the producer and consumer,. Which lead to race
condition.

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 6.2 Silberschatz, Galvin and Gagne ©2018

Race Condition Critical Section Problem

 Processes P0 and P1 are creating child processes using the fork()  Consider system of n processes {p0, p1, … pn-1}
system call
 Each process has critical section segment of code
 Race condition on kernel variable next_available_pid which
• Process may be changing common variables, updating table,
represents the next available process identifier (pid)
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

 Unless there is a mechanism to prevent P0 and P1 from accessing the

variable next_available_pid the same pid could be assigned to
two different processes!

Operating System Concepts – 10th Edition 6.3 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 6.4 Silberschatz, Galvin and Gagne ©2018
 Critical Section Critical-Section Problem (Cont.)

 General structure of process Pi Requirements for 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 process 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 – 10th Edition 6.5 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 6.6 Silberschatz, Galvin and Gagne ©2018

Solution to CS Problem Using Mutex Locks Mutex Locks

 OS designers build software tools to solve critical section problem
 Simplest is mutex lock
• Boolean variable indicating if lock is available or not
 Protect a critical section by
while (true) {
acquire lock • First acquire() a lock
• Then release() the lock
critical section
 Calls to acquire() and release() must be atomic
release lock • Usually implemented via hardware atomic instructions such as
compare-and-swap.
remainder section  But this solution requires busy waiting
} • This lock therefore called a spinlock

Operating System Concepts – 10th Edition 6.7 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 6.8 Silberschatz, Galvin and Gagne ©2018
 Semaphore Semaphore (Cont.)

 Synchronization tool that provides more sophisticated ways  Counting semaphore – integer value can range over
(than Mutex locks) for processes to synchronize their activities. an unrestricted domain
 Semaphore S – integer variable  Binary semaphore – integer value can range only
 Can only be accessed via two indivisible (atomic) operations between 0 and 1
• wait() and signal() • Same as a mutex lock
 Originally called P() and V()
 Can implement a counting semaphore S as a binary
 Definition of the wait() operation semaphore
wait(S) {  With semaphores we can solve various synchronization
while (S <= 0) problems
; // busy wait
S--;
}
 Definition of the signal() operation
signal(S) {
S++;
}

Operating System Concepts – 10th Edition 6.9 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 6.10 Silberschatz, Galvin and Gagne ©2018

Semaphore Usage Example Semaphore Implementation

 Solution to the CS Problem  Must guarantee that no two processes can execute the wait()
• Create a semaphore “mutex” initialized to 1 and signal() on the same semaphore at the same time
wait(mutex);  Thus, the implementation becomes the critical section problem
CS where the wait and signal code are placed in the critical
section
signal(mutex);
 Could now have busy waiting in critical section implementation
 Consider P1 and P2 that with two statements S1 and S2 and
the requirement that S1 to happen before S2 • But implementation code is short
• Create a semaphore “synch” initialized to 0 • Little busy waiting if critical section rarely occupied
P1:  Note that applications may spend lots of time in critical sections
S1; and therefore this is not a good solution

signal(synch);
P2:
wait(synch);
S 2;

Operating System Concepts – 10th Edition 6.11 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 6.12 Silberschatz, Galvin and Gagne ©2018
 Semaphore Implementation with no Busy waiting Classical Problems of Synchronization
 With each semaphore there is an associated waiting queue  Classical problems used to test newly-proposed
 Each entry in a waiting queue has two data items: synchronization schemes
• Value (of type integer) • Bounded-Buffer Problem (Not discussed)
• Pointer to next record in the list • Readers and Writers Problem
 Two operations: • Dining-Philosophers Problem (Not discussed)
• 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

Operating System Concepts – 10th Edition 6.13 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 7.14 Silberschatz, Galvin and Gagne ©2018

Readers/Writers Problem Readers-Writers Problem

 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
An object is shared among several threads
 updates
 Some threads only read the object, others only write it • Writers – can both read and write
 We can allow multiple readers but only one writer  Problem – allow multiple readers to read at the same time
• Only one single writer can access the shared data at the same
Let #r be the number of readers, #w be the number of time
writers  Several variations of how readers and writers are considered – all
Safety: (#r ≥ 0) ∧ (0 ≤ #w ≤ 1) ∧ ((#r > 0) ⇒ (#w = 0)) involve some form of priorities

 How can we use semaphores to control access to the

object to implement this protocol?

Operating System Concepts – 10th Edition 7.15 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 7.16 Silberschatz, Galvin and Gagne ©2018
 Readers-Writers Problem (Cont.) Readers-Writers Problem (Cont.)
 Shared Data
 The structure of a writer process
• Data set
• Semaphore rw_mutex initialized to 1
while (true) {
• Semaphore mutex initialized to 1 wait(rw_mutex);
• Integer read_count initialized to 0 ...
/* writing is performed */
...
signal(rw_mutex);
}

Operating System Concepts – 10th Edition 7.17 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 7.18 Silberschatz, Galvin and Gagne ©2018

Readers-Writers Problem (Cont.) Readers-Writers Problem Variations

 The structure of a reader process  The solution in previous slide can result in a situation where
while (true){ a writer process never writes. It is referred to as the “First
wait(mutex); reader-writer” problem.
read_count++;
if (read_count == 1) /* first reader */  The “Second reader-writer” problem is a variation the first
reader-writer problem that state:
wait(rw_mutex);
signal(mutex); • Once a writer is ready to write, no “newly arrived
reader” is allowed to read.
...
/* reading is performed */  Both the first and second may result in starvation. leading to
... even more variations
wait(mutex);  Problem is solved on some systems by kernel providing
read_count--; reader-writer locks
if (read_count == 0) /* last reader */
signal(rw_mutex);
signal(mutex);
}

Operating System Concepts – 10th Edition 7.19 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 7.20 Silberschatz, Galvin and Gagne ©2018
 System Model

 System consists of resources

 Resource types R1, R2, . . ., Rm
• CPU cycles, memory space, I/O devices
Synchronization (Deadlock)  Each resource type Ri has Wi instances.
 Each process utilizes a resource as follows:
• request
• use
• release

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.22 Silberschatz, Galvin and Gagne ©2018

Deadlock with Semaphores Deadlock Characterization

 Data: Deadlock can arise if four conditions hold simultaneously.

• A semaphore S1 initialized to 1  Mutual exclusion: only one thread at a time can use a
• A semaphore S2 initialized to 1 resource

 Two threads T1 and T2  Hold and wait: a thread holding at least one resource is
waiting to acquire additional resources held by other threads
 T1:
 No preemption: a resource can be released only voluntarily
wait(s1) by the thread holding it, after that thread has completed its
wait(s2) task
 T2:  Circular wait: there exists a set {T0, T1, …, Tn} of waiting
wait(s2) threads such that T0 is waiting for a resource that is held by
T1, T1 is waiting for a resource that is held by T2, …, Tn–1 is
wait(s1) waiting for a resource that is held by Tn, and Tn is waiting for a
resource that is held by T0.

Operating System Concepts – 10th Edition 8.23 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.24 Silberschatz, Galvin and Gagne ©2018
 Resource-Allocation Graph Resource Allocation Graph Example

A set of vertices V and a set of edges E.  One instance of R1

 Two instances of R2
 V is partitioned into two types:
 One instance of R3
• T = {T1, T2, …, Tn}, the set consisting of all the threads
in the system.  Three instance of R4
 T1 holds one instance of R2 and is
• R = {R1, R2, …, Rm}, the set consisting of all resource waiting for an instance of R1
types in the system  T2 holds one instance of R1, one
instance of R2, and is waiting for an
 request edge – directed edge Ti  Rj instance of R3

 assignment edge – directed edge Rj  Ti  T3 is holds one instance of R3

Operating System Concepts – 10th Edition 8.25 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.26 Silberschatz, Galvin and Gagne ©2018

Resource Allocation Graph with a Deadlock Graph with a Cycle But no Deadlock

Operating System Concepts – 10th Edition 8.27 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.28 Silberschatz, Galvin and Gagne ©2018
 Basic Facts Methods for Handling Deadlocks

 If graph contains no cycles  no deadlock  Ensure that the system will never enter a deadlock state:
 If graph contains a cycle  • Deadlock prevention
• if only one instance per resource type, then deadlock • Deadlock avoidance
• if several instances per resource type, possibility of deadlock  Allow the system to enter a deadlock state and then recover
 Ignore the problem and pretend that deadlocks never occur in the
system.

Operating System Concepts – 10th Edition 8.29 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.30 Silberschatz, Galvin and Gagne ©2018

Deadlock Prevention Deadlock Prevention (Cont.)

Invalidate one of the four necessary conditions for deadlock:  No Preemption:
• If a process that is holding some resources requests another
 Mutual Exclusion – not required for sharable resources (e.g., resource that cannot be immediately allocated to it, then all
read-only files); must hold for non-sharable resources resources currently being held are released
 Hold and Wait – must guarantee that whenever a thread requests • Preempted resources are added to the list of resources for which
a resource, it does not hold any other resources the thread is waiting
• Require threads to request and be allocated all its resources • Thread will be restarted only when it can regain its old resources,
before it begins execution or allow thread to request as well as the new ones that it is requesting
resources only when the thread has none allocated to it.  Circular Wait:
• Low resource utilization; starvation possible • Impose a total ordering of all resource types, and require that each
thread requests resources in an increasing order of enumeration

Operating System Concepts – 10th Edition 8.31 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.32 Silberschatz, Galvin and Gagne ©2018
 Deadlock Avoidance Safe State
Requires that the system has some additional a priori information  When a thread requests an available resource, system must decide
available if immediate allocation leaves the system in a safe state
 Simplest and most useful model requires that each thread declare  System is in safe state if there exists a sequence <T1, T2, …, Tn>
the maximum number of resources of each type that it may need of ALL the threads in the systems such that for each Ti, the
 The deadlock-avoidance algorithm dynamically examines the resources that Ti can still request can be satisfied by currently
resource-allocation state to ensure that there can never be a available resources + resources held by all the Tj, with j < I
circular-wait condition  That is:
 Resource-allocation state is defined by the number of available and • If Ti resource needs are not immediately available, then Ti can
allocated resources, and the maximum demands of the processes wait until all Tj have finished
• When Tj is finished, Ti can obtain needed resources, execute,
return allocated resources, and terminate
• When Ti terminates, Ti +1 can obtain its needed resources, and
so on

Operating System Concepts – 10th Edition 8.33 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.34 Silberschatz, Galvin and Gagne ©2018

Basic Facts Safe, Unsafe, Deadlock State

 If a system is in safe state  no deadlocks

 If a system is in unsafe state  possibility of deadlock

 Avoidance  ensure that a system will never enter an unsafe state.

Operating System Concepts – 10th Edition 8.35 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.36 Silberschatz, Galvin and Gagne ©2018
 Avoidance Algorithms Resource-Allocation Graph Scheme
 Single instance of a resource type  Claim edge Ti  Rj indicated that process Tj may request resource
• Use a resource-allocation graph Rj; represented by a dashed line
 Claim edge converts to request edge when a thread requests a
resource
 Multiple instances of a resource type
 Request edge converted to an assignment edge when the resource
• Use the Banker’s Algorithm is allocated to the thread
 When a resource is released by a thread, assignment edge
reconverts to a claim edge
 Resources must be claimed a priori in the system

Operating System Concepts – 10th Edition 8.37 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.38 Silberschatz, Galvin and Gagne ©2018

Resource-Allocation Graph Unsafe State In Resource-Allocation Graph

Operating System Concepts – 10th Edition 8.39 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.40 Silberschatz, Galvin and Gagne ©2018
 Resource-Allocation Graph Algorithm Banker’s Algorithm
 Suppose that thread Ti requests a resource Rj  Multiple instances of resources
 The request can be granted only if converting the request edge to an  Each thread must a priori claim maximum use
assignment edge does not result in the formation of a cycle in the  When a thread requests a resource, it may have to wait
resource allocation graph
 When a thread gets all its resources it must return them in a finite
amount of time

Operating System Concepts – 10th Edition 8.41 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.42 Silberschatz, Galvin and Gagne ©2018

Data Structures for the Banker’s Algorithm Safety Algorithm

Let n = number of processes, and m = number of resources types. 1. Let Work and Finish be vectors of length m and n, respectively.
Initialize:
 Available: Vector of length m. If available [j] = k, there are k Work = Available
instances of resource type Rj available
Finish [i] = false for i = 0, 1, …, n- 1
 Max: n x m matrix. If Max [i,j] = k, then process Ti may request at
most k instances of resource type Rj
2. Find an i such that both:
(a) Finish [i] = false
 Allocation: n x m matrix. If Allocation[i,j] = k then Ti is currently (b) Needi  Work
allocated k instances of Rj
If no such i exists, go to step 4
 Need: n x m matrix. If Need[i,j] = k, then Ti may need k more
instances of Rj to complete its task 3. Work = Work + Allocationi
Finish[i] = true
go to step 2
Need [i,j] = Max[i,j] – Allocation [i,j]
4. If Finish [i] == true for all i, then the system is in a safe state

Operating System Concepts – 10th Edition 8.43 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.44 Silberschatz, Galvin and Gagne ©2018
 Resource-Request Algorithm for Process Pi Example of Banker’s Algorithm
Requesti = request vector for process Ti. If Requesti [j] = k then
process Ti wants k instances of resource type Rj  5 threads T0 through T4;
1. If Requesti  Needi go to step 2. Otherwise, raise error 3 resource types:
condition, since process has exceeded its maximum claim A (10 instances), B (5instances), and C (7 instances)
2. If Requesti  Available, go to step 3. Otherwise Ti must wait,  Snapshot at time T0:
since resources are not available
Allocation Max Available
3. Pretend to allocate requested resources to Ti by modifying the
state as follows: ABC ABC ABC

Available = Available – Requesti; T0 010 753 332

Allocationi = Allocationi + Requesti; T1 200 322

Needi = Needi – Requesti; T2 302 902

• If safe  the resources are allocated to Ti T3 211 222

• If unsafe  Ti must wait, and the old resource-allocation state T4 002 433
is restored

Operating System Concepts – 10th Edition 8.45 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.46 Silberschatz, Galvin and Gagne ©2018

Example (Cont.) Example: P1 Request (1,0,2)

 The content of the matrix Need is defined to be Max – Allocation  Check that Request  Available (that is, (1,0,2)  (3,3,2)  true
Allocation Need Available
Need ABC ABC ABC
ABC T0 010 743 230
T0 743 T1 302 020
T1 122 T2 302 600
T2 600 T3 211 011
T3 011 T4 002 431
T4 431
 Executing safety algorithm shows that sequence < T1, T3, T4, T0, T2>
satisfies safety requirement
 The system is in a safe state since the sequence < T1, T3, T4, T2, T0>
satisfies safety criteria  Can request for (3,3,0) by T4 be granted?

 Can request for (0,2,0) by T0 be granted?

Operating System Concepts – 10th Edition 8.47 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 8.48 Silberschatz, Galvin and Gagne ©2018