Good

1. 9 – Synchronization

2. Classical Synchronization Problems
❑Producer Consumer
❑Readers Writers
❑Sleeping Barber
❑Cigarette Smokers (Reading Assignment)
❑Dining Philosophers Problem

3. Producer Consumer
❑ One process producing items and writing on a buffer
❑ Another process consuming items from the buffer
❑ Buffer is bounded.
❑ Applications
▪ Pre-processor produces source file for compiler’s parser
▪ Data from bar-code reader consumed by device driver
▪ Printing file data
▪ Web server produces data consumed by client’s web
browser
▪ “pipe” ( | ) in Unix >cat file | sort | more

4. Readers Writers
❑There are multiple readers and multiple writers.
❑Writers write but at a time only one writer is allowed to
proceed.
❑Readers can read concurrently.
❑Constraints are
▪ Only one writer can be in critical section; no other writer
or reader is allowed to be in critical section
▪ Many readers can be in critical section but there should
be no writer in critical section

5. Readers Writers: Application
❑Many processes accessing data from a database
▪ Some processes are reading data
▪ Some processes are attempting to write data
▪ Only one process should be allowed to write
▪ Many processes can read concurrently but no writing should
be allowed to ensure that all processes read same data
❑Online reservation systems – railways, bus transport,
airline

6. Readers Writers – Solution 1
semaphore resource=1, rmutex=1; integer readcount=0;
writer() {
// only one writer can enter CS
wait(resource);
Critical Section
signal(resource);
}
reader() {
wait(rmutex);
readcount++;
if (readcount == 1) // first reader
wait(resource); // writers not allowed in CS
signal(rmutex);
// Do the Reading
wait(rmutex);
readcount--;
if (readcount == 0) // last reader
signal(resource); //writers allowed in CS
signal(rmutex);
}
Readers’ Preference

7. Readers’ Preference Solution
❑Semaphore resource
▪ To ensure that there is only one writer in CS
❑Semaphore rmutex to prevent race condition among
reader threads when shared variable readCount is
modified
❑First reader blocks writers; entry to CS
❑As long as there is any active reader reading, other
readers can continue to reading
❑When last reader leaves reading, writers entry to CS is
allowed.

8. Readers Writers – Solution 2
integer readcount = 0, writecount = 0;
semaphore rmutex = 1, wmutex = 1, readTry = 1, resource = 1;
writer() {
wait(wmutex);
writecount++;
if (writecount == 1)
wait(readTry);
signal(wmutex);
wait(resource);
Critical Section
signal(resource);
wait(wmutex);
writecount--;
if (writecount == 0)
signal(readTry);
signal(wmutex);
}
reader() {
wait(readTry);
wait(rmutex);
readcount++;
if (readcount == 1) // first reader
wait(resource); // writers not allowed in CS
signal(rmutex);
signal(readTry);
// Do the Reading
wait(rmutex);
readcount--;
if (readcount == 0) // last reader
signal(resource); //writers allowed in CS
signal(rmutex);
}
Writers’ Preference

9. Writers’ Preference Solution
❑ Semaphore resource to ensure only one writer in CS
▪ Writers waiting on resource enter CS one by one
❑ Semaphore readTry:
▪ First writer blocks entry of readers; Last writer unblocks
▪ First reader blocks on readTry ; Other readers block on mutex
❑ Semaphore rmutex to prevent race condition among readers
for shared variable readCount
❑ Semaphore wmutex to prevent race condition among writers
for shared variable writeCount
❑ Once a reader is active, all readers get to go through
▪ The last reader to exit signals a writer

10. Readers Writers – Solution 3
integer readcount = 0, writecount = 0;
semaphore rmutex = 1, wmutex = 1, serviceQueue = 1;
writer() {
wait(serviceQueue);
wait(resource);
signal(serviceQueue);
Critical Section
signal(resource);
}
reader() {
wait(serviceQueue);
wait(rmutex);
readcount++;
if (readcount == 1) // first reader
wait(resource); // writers not allowed in CS
signal(rmutex);
signal(serviceQueue);
// Do the Reading
wait(rmutex);
readcount--;
if (readcount == 0) // last reader
signal(resource); //writers allowed in CS
signal(rmutex);
}
Fairness: no thread is starved.
serviceQueue need to preserve
first-in first-out order when
blocking and releasing threads.

11. Sleeping Barber Problem
❑ One barber, one barber chair, a waiting area with N chairs
❑ Barber cuts hair of the customer in barber chair. After finishing,
goes to waiting area to invite next customer for a haircut. If no
customer, barber goes to sleep
❑ A customer enters the shop only if a chair is empty
▪ If barber chair is empty, customer sits in this, wakes up
barber who proceeds with hair-cutting
▪ Customer takes one chair in waiting hall
❑ Applications: A server serving requests of multiple clients
through a buffer in which only finite number of requests can be
accommodated.

12. Sleeping Barber – Solution
semaphore bReady = 0, accessChair = 1, cReady = 0; integer nFreeChair = N;
Barber( ) {
while( true ) {
wait( cReady )
wait( accessChair )
nFreeChair ++
signal( bReady )
signal( accessChair )
// Cut hair
}
}
Customer( ) {
while( true ) {
wait( accessChair )
if( nFreeChair > 0 ) {
nFreeChair --
signal( cReady )
signal( accessChair )
wait( bReady )
// Hair cutting begins
}
else {
signal( accessChair )
}
}
}

13. Sleeping Barber Variant: Assignment
❑ 3 barbers, 3 barber chairs, 5 chairs in waiting area, standing room
for additional 10 customers
❑ Customer enters only if shop not filled to capacity
▪ Takes barber chair, if empty
▪ Takes waiting area chair, if available; otherwise stands
❑ A free barber serves customer in FIFO from waiting area chairs;
standing customers move to chairs in FIFO manner
❑ When a customer’s haircut is finished, any barber can accept
payment, but payment is accepted for one customer at a time as
there is single cash register.
❑ Barbers divide their time among cutting hair, accepting payment,
and sleeping in their chair waiting for a customer.

14. Dining Philosophers Problem
❑Five philosophers dining; round dining table
❑Five dinner plates and five forks available
❑A philosopher either thinks or eats
❑Needs two forks to eat food
❑What if each philosopher picks up one fork; keeps
holding it while trying to gain access to other fork
▪ Each philosopher left with one fork each
▪ Deadlock

15. Deadlock
❑Deadlock: A set of processes is unable to change their
state indefinitely because the resources requested are
being used by other waiting processes.
▪ A deadlock occurs when a process or thread enters a waiting
state because required resource is held by another waiting
process, which in turn is waiting for a resource held by
another waiting process.
❑Livelock: the states of the processes involved constantly
change with regard to one another, consuming CPU
cycles but with no real progress.

16. Semaphore – Mutual Exclusion
S = 1
wait(S)
critical Section
signal(S)
Incorrect usage of semaphores can lead to
problems.

17. sem S = 0
wait(S)
critical section
signal(S)
All processes including the first one sleep on S. signal(S) can
not be invoked to wake these.
wait(S)
critical section
wait(S)
Running process sleeps on second wait(S). Subsequent
processes freeze on first wait(S).
Deadlock
signal(S)
critical section
signal(S)
Undermines mutex:
• no wait(S) to block a process
• “extra” signal(S) allow other processes
into the critical section violating mutual exclusion
wait(S)
critical section
Next call to wait(S) will block the process
wait(S)
if()
return;
critical section
signal(S)
The process satisfying condition x return without invoking
signal(S). As a result blocked processes on wait(S) remain
sleeping. Also when the same process executes wait(S), it shall
also goto sleep.
Deadlock

18. Deadlock – 2 process
semaphore S1 = 1, S2 = 1;
wait( S1 )
wait( S2 )
critical section
signal( S2 )
signal( S1 )
wait( S2 )
wait( S1 )
critical section
signal( S1 )
signal( S2 )

19. Deadlock – 3 process
semaphore S1 = 1, S2 = 1, S3 = 1;
wait( S1 )
wait( S2 )
critical
section
signal( S2 )
signal( S1 )
wait( S2 )
wait( S3 )
critical
section
signal( S3 )
signal( S2 )
wait( S3 )
wait( S1 )
critical
section
signal( S1 )
signal( S3 )

20. Deadlock: Necessary & Sufficient Conditions
❑Mutual Exclusion: resource accessible in mutual exclusion
mode i.e. only one process can access it
❑Hold and Wait: process acquires a resource and keeps
holding it while waiting for acquisition of other resources
❑No Preemption: resources can’t be taken from a process
❑Circular Wait: There exists a set of processes
▪ is waiting on resource held by
▪ is waiting on resource held by
▪ …
▪ is waiting on resource held by

21. Preventing Deadlock
❑ Mutual Exclusion
▪ Include enough resources so that no one ever runs out of
resources.
▪ create illusion of many resources (virtualization)
❑ Hold and Wait
▪ processes to request all requisite resources at the
beginning.
▪ Resource allocation: all or none; process not allowed to hold
resources if it requires additional
❑ Cyclic Wait
▪ Force all threads to request resources in a particular order
preventing any cyclic use of resources

22. Deadlock Detection
❑Two types of nodes - process and resource
❑A edge from a resource node to process node
▪ resource allocated to process
❑A edge from a process node to resource node
▪ process waiting on resource
❑If each resource has exactly one instance
▪ deadlock cycle in resource allocation graph
≡
❑If multiple instances of resource(s)
▪ deadlock no safe state in Banker’s algorithm
≡

23. Resource Allocation Graph
.
.
.
.
.
. .
R1 R3
R2
P3
P2
.
.
.
.
.
.
. .
R3
R1
P1 P2 P3
P4
R2
R4
Cycles:
P1-R1-P2-R3-P3-R2-P1
P2-R3-P3-R2-P2
and there is deadlock.
No deadlock
P1
R4

24. Resource Allocation Graph
Cycles:
P1-R1-P2-R3-P3-R2-P1
P2-R3-P3-R2-P2
and there is deadlock.
Cycle but no deadlock
.
.
.
.
.
. .
R1 R3
R2
P3
P2
P1
R4
.
.
.
.
.
. .
R1 R3
R2
P3
P2
P1
R4

25. Dining Philosophers - Solution 1
❑Each philosopher tries to acquire both forks.
❑If successful
▪ Philosopher starts eating
❑Otherwise
▪ Places acquired fork on table
❑Infinite postponement may take place

26. Dining Philosophers – Solution 2
❑Philosophers P1, P2, P3, P4 try to acquire
▪ left fork and then right fork
❑Philosopher P5 acquires
▪ right fork and then left fork
❑Contention for same fork - P5 and neighbor
▪ If P5 is successful on right fork, his right neighbor
fails to pick up left fork and stops participating
▪ Else P5 gives up
▪ Either way, 4 philosopher and 5 forks; so one
philosopher receives 2 forks and can eat

27. Dining Philosophers – Solution 3
❑P1, P3, P5 (odd numbered philosopher) pick
▪ First left fork and then right fork,
❑P2, P4 (even numbered philosopher) pick
▪ First right and then left fork,
❑Contention for same fork
▪ Two pairs of philosophers
▪ Two philosophers have to give up
▪ 5 forks, 3 contenders – 2 philosophers can dine

28. Dining Philosophers – Solution 4
❑Restrict number of philosophers intending to eat to
four only
❑Allow these four to compete for forks

29. Dining Philosophers – Solution 5
❑ Forks are numbered. Each philosopher
▪ can pick only a given pair of forks.
▪ tries to acquire lower numbered fork first.
❑ If four philosopher pick up their lower-numbered fork, highest-
numbered fork remains; fifth philosopher does not get lower
numbered fork and is out of competition.
❑ Only one philosopher will have access to highest-numbered fork
and gets to eat.
❑ Not practical: Computer programs that access large numbers of
database records would not run efficiently if they were required to
release all higher-numbered records before accessing a new
record.

30. Dining Philosophers – Solution 6
❑To pick up forks, a philosopher seeks permission of
arbitrator.
❑Arbitrator gives permission to only one philosopher
❑Selected philosopher picks up both forks and can eat.
❑Putting down a fork is always allowed.
❑Arbitrator ensures
▪ philosopher acquires both forks or none
▪ there is no deadlock
▪ Implemented as a mutex

31. Dining Philosophers – Solution 7
❑Chandy Misra – Reading Assignment

32. Thank you.