1. CS 149: Operating Systems February 24 Class Meeting
Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak

2. Example Multithreading Program
Simulation of students visiting a professor during her office hour.
Only one student can be in the office at a time.
Three chairs outside the office for waiting students.
Student leaves immediately if there are no available chairs.
Written in C using the Pthreads library.
Contains a subtle threading bug!
Causes a deadlock under certain circumstances.
Can you find the error and correct it? _
Demo
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

3. CS 149: Operating Systems © R. Mak
Assignment #3
Create a multithreaded simulation of concert ticket sellers during one hour.
100 seats available.
High-price ticket seller named H.
Requires randomly exactly 1 or 2 minutes per ticket sale.
Medium-price ticket sellers named M1, M2, and M3.
Each requires randomly exactly 2, 3, or 4 minutes per sale.
Low-price ticker sellers named L1, L2, L3, L4, L5, and L6.
Each requires randomly exactly 4, 5, 6, or 7 minutes per sale.
N customers per seller arrive randomly during the hour.
N is a command-line parameter.
For simplicity, customers arrive only at the start of a minute.
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

4. CS 149: Operating Systems © R. Mak
Assignment #3, cont’d
All ten ticket sellers work collaboratively.
Each serves customers in the order they arrive in his queue.
First check to see if there are still seats available.
If none, the customer leaves immediately.
Take the required number of minutes to complete the sale.
Then the customer leaves.
Ensure that two customers aren’t assigned to the same seat.
The concert has ten rows of ten seats each.
Ticket seller H assigns seats starting in row 1 and works back.
Ticket sellers L1 - L6 assign seats starting in row 10 and work forward.
Ticket sellers M1, M2, and M3 assign seats starting in row 5, then row 6, then row 4, then row 7, etc.
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

5. CS 149: Operating Systems © R. Mak
Assignment #3, cont’d
Print a line for each event that occurs:
A customer arrives at the tail of a seller’s queue.
A customer is served and is assigned a seat, or is told the concert is sold out, in which case the customer immediately leaves.
A customer completes a ticket purchase and leaves.
Start each event print line with a time stamp, such as 0:05, 0:12, etc. _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

6. CS 149: Operating Systems © R. Mak
Assignment #3, cont’d
After each ticket sale, also print the concert seating chart as a 10-by-10 matrix.
Show which customer was assigned to each seat.
Identify ticket seller H’s customers as H001, H002, H003, ...
Identify the customers of ticket sellers M1, M2, …, as M101, M102, …, M201, M202, …
Identify the customers of ticket sellers L1, L2, … as L101, L102, …, L201, L202, ...
Indicate unsold seats with dashes.
At the end of the hour, or when all the tickets are sold:
Each ticket seller completes any sale still in progress.
Remaining customers in the queues immediately leave.
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

7. CS 149: Operating Systems © R. Mak
Assignment #3, cont’d
Simulate the events that occur during one hour.
1 second real time = 1 minute simulated time.
Your program should run for 60 seconds, where each second simulates one minute. `
Write your program in C or C++
Use the Pthreads library.
Run your program for N = 5, 10, and 15 customers per ticket seller.
N is a command-line parameter.
At the end of each run, print how many H, M, and L customers got seats, how many customers were turned away, etc. _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

8. CS 149: Operating Systems © R. Mak
Assignment #3, cont’d
Tips
Simulate each ticket seller and customer with a separate thread.
Customers arrive at random times during the hour:
Each customer initially sleep randomly integer 0 – 59 seconds.
Upon waking, the customer arrives at the ticket queue.
A seller sleeps the appropriate random number of seconds to simulate taking the minutes to complete a ticket sale.
What are the critical regions?
What process synchronization is required?
Extra credit (10 points)
Impatient customers leave after waiting 10 minutes in a ticket queue. _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

9. CS 149: Operating Systems © R. Mak
Assignment #3, cont’d
Turn in a zip file containing:
Your C or C++ source files.
A text file containing output from your simulation runs.
A 1- or 2-page report that describes your software design.
What parameters did you adjust to make the simulation run realistically?
What data was shared and what were the critical regions?
What process synchronization was required?
Note clearly in your report if you did the extra credit.
Important
Name your zip file after your team name.
Example: SuperCoders.zip
Subject line: CS 149-section Assignment #3, team name
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

10. CS 149: Operating Systems © R. Mak
Deadlocks
Deadlocks, AKA the Deadly Embrace
In either case, your application is hung.
What happened?
Deadlocks can occur when a set of processes are contending for resources.
The sequence of events required for a process to use a resource:
Request the resource.
Use the resource.
Release the resource. _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

11. CS 149: Operating Systems © R. Mak
Deadlocks, cont’d
Deadlocks can occur when the OS grants processes exclusive access to resources.
Hardware devices (e.g., DVD reader)
Memory
Data
A resource is anything that can be used by only a single process at a time.
A process may need to have exclusive access to several resources at a time.
Resources are preemptable and nonpreemptable. _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

12. Deadlocks over Resources
Preemptable resource
Can be taken away from a process that owns it.
No ill effects on the process.
Example: memory
Nonpreemptable resource
Cannot be taken away from the process owning it without causing the process to fail.
Example: CD recorder
If a process requests a resource that is not available, then the process must wait.
The OS may unblock the process when the resource becomes available again.
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

13. CS 149: Operating Systems © R. Mak
Deadlock Definition
A set of processes is deadlocked if:
Each process in the set is waiting for an event.
Only another process in the set can cause the event.
If all the processes are waiting, none of them can cause the event that wakes up the blocked processes. _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

14. CS 149: Operating Systems © R. Mak
Deadlock Conditions
Mutual exclusion
Each resource is either available or currently assigned to exactly one process.
Hold and wait
Processes currently holding resources that were granted earlier can request new resources.
No preemption
A resource previously granted to a process cannot be forcibly taken away from the process. The process must explicitly release the resource.
Circular wait
A circular chain of process, each waiting for a resource held by another process in the chain.
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

15. CS 149: Operating Systems © R. Mak
Deadlock Modeling
Resource allocation graphs
Two types of nodes: processes (shown as circles) and resources (shown as squares).
(a) Process A holds resource R.
(b) Process B requests resource S.
(c) A deadlock situation.
Modern Operating Systems, 3rd ed.
Andrew Tanenbaum
(c) 2008 Prentice-Hall, Inc
All rights reserved
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

16. Deadlock Modeling, cont’d
Process C waits for Resource T, which is held by Process D.
Process D waits for Resource U, which is held by Process C.
Deadlock cycle: C  T  D  U  C
Modern Operating Systems, 3rd ed.
Andrew Tanenbaum
(c) 2008 Prentice-Hall, Inc
All rights reserved
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

17. Deadlock Modeling, cont’d
Suppose we have three processes A, B, and C that are competing for resources R, S, and T.
Their requests and releases:
The process scheduler is free to run any unblocked process at any instant. _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

18. Deadlock Modeling, cont’d
One solution: The scheduler allows Process A to run to completion, then Process B, and finally Process C.
No competition for resources  no deadlocks.
But also no parallelism. _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

19. Deadlock Modeling, cont’d
What happens if we use the Round-Robin instead?
A blocks
B blocks
C blocks
Modern Operating Systems, 3rd ed.
Andrew Tanenbaum
(c) 2008 Prentice-Hall, Inc
All rights reserved
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

20. Deadlock Modeling, cont’d
Would a different scheduling order help?
Process B
is suspended.
What happens
now if Process B
wakes up?
Modern Operating Systems, 3rd ed.
Andrew Tanenbaum
(c) 2008 Prentice-Hall, Inc
All rights reserved
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

21. Pthreads Deadlock Example
int worker1_id;
int worker2_id;
void *worker1(void *param);
void *worker2(void *param);
pthread_mutex_t mtx1;
pthread_mutex_t mtx2;
int main(int argc, char *argv[]) {
srand(time(0));
pthread_mutex_init(&mtx1, NULL);
pthread_mutex_init(&mtx2, NULL);
... }
Where is
there a
potential
deadlock
lurking in
this code?
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

22. Pthreads Deadlock Example, cont’d
...
int main(int argc, char *argv[]) {
printf("main: Create worker 1 thread.\n");
worker1_id = 1;
pthread_t worker1_tid;
pthread_attr_t worker1_attr;
pthread_attr_init(&worker1_attr);
pthread_create(&worker1_tid, &worker1_attr, worker1, &worker1_id);
printf("main: Create worker 2 thread.\n");
worker2_id = 2;
pthread_t worker2_tid;
pthread_attr_t worker2_attr;
pthread_attr_init(&worker2_attr);
pthread_create(&worker2_tid, &worker2_attr, worker2, &worker2_id);
printf("main: Wait for workers to finish.\n");
pthread_join(worker1_tid, NULL);
pthread_join(worker2_tid, NULL);
printf("main: Done!"); }
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

23. Pthreads Deadlock Example, cont’d
void *worker1(void *param) {
printf("Worker1: Locking mutex 1.\n");
pthread_mutex_lock(&mtx1);
sleep(rand()%3);
printf("Worker1: Locking mutex 2.\n");
pthread_mutex_lock(&mtx2);
printf("Worker1: Working.\n");
sleep(rand()%5);
printf("Worker1: Unlocking mutex 2.\n");
printf("Worker1: Unlocking mutex 1.\n"); }
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

24. Pthreads Deadlock Example, cont’d
void *worker2(void *param) {
printf("Worker2: Locking mutex 2.\n");
pthread_mutex_lock(&mtx2);
sleep(rand()%3);
printf("Worker2: Locking mutex 1.\n");
pthread_mutex_lock(&mtx1);
printf("Worker2: Working.\n");
sleep(rand()%5);
printf("Worker2: Unlocking mutex 1.\n");
printf("Worker2: Unlocking mutex 2.\n"); }
Demo
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

25. CS 149: Operating Systems © R. Mak
Deadlock Strategies
Ignore the problem altogether.
Detection and recovery.
Avoidance by careful resource allocation.
Prevention by negating one of the four necessary conditions.
Mutual exclusion
Hold and wait
No preemption
Circular wait _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

26. CS 149: Operating Systems © R. Mak
Ignore Deadlocks
Deadlocks may be unavoidable when there are limited resources.
The OS can impose draconian measures to prevent deadlocks that happen only occasionally.
If there are too many restrictions on the use of resources, the cost in inconvenience is too high.
Users may rather tolerate infrequent system lockups. _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

27. Deadlock Detection and Recovery
The OS monitors resource requests and releases.
It maintains an internal resource allocation graph.
If it detects any cycles, it starts to kill processes one by one until the cycle is broken.
The OS periodically checks to see if any processes have been continuously blocked for a long time.
Kill off such processes. _
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

28. CS 149: Operating Systems © R. Mak
Deadlock Prevention
Relax mutual exclusion
Never assign a resource exclusively to a process.
Example: Instead of processes contending for the use of a printer, use spooling instead.
But not all resources can be spooled. _
Mutual exclusion
Hold and wait
No preemption
Circular wait
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

29. Deadlock Prevention, cont’d
Require all processes to request all their resources before starting execution.
A process waits if any one resource is unavailable.
No process will hold some resources and block waiting for others.
But not all process know what resources they need ahead of time.
Poor use of resources.
Example: A process reads data from a shared tape drive, processes the data for an hour, and writes results to the tape drive. It locks up the tape drive for an hour. _
Mutual exclusion
Hold and wait
No preemption
Circular wait
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

30. Deadlock Prevention, cont’d
Require that a process that requests a resource:
First release all the resources that it currently holds.
Then try to acquire all its required resources all at once. _
Mutual exclusion
Hold and wait
No preemption
Circular wait
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

31. Deadlock Prevention, cont’d
Forcibly take a resource away from a process if a higher priority process requests that resource.
Can you interrupt a print job for a higher priority one? _
Mutual exclusion
Hold and wait
No preemption
Circular wait
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

32. Deadlock Prevention, cont’d
Allow a process only one resource at a time.
Too restrictive.
Global numbering of all resources.
Processes can requests all the resources they want, but only in numerical order.
Mutual exclusion
Hold and wait
No preemption
Circular wait
Modern Operating Systems, 3rd ed.
Andrew Tanenbaum
(c) 2008 Prentice-Hall, Inc
All rights reserved
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

33. Deadlock Prevention, cont’d
Global numbering of all resources:
Process A requests Resource i.
Process B requests Resource j.
If i > j, then process A cannot request Resource j.
if i < j, then process B cannot request Resource i.
Therefore, no deadlock can occur.
It may be hard to devise a workable ordering.
Modern Operating Systems, 3rd ed.
Andrew Tanenbaum
(c) 2008 Prentice-Hall, Inc
All rights reserved
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak

34. Deadlock Prevention, cont’d
Department of Computer Science
Spring 2014: February 24
CS 149: Operating Systems © R. Mak