CS 149: Operating Systems February 24 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak www.cs.sjsu.edu/~mak

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

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

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

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

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

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

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

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

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

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

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

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

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

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.. 0-13-600663-9 All rights reserved Department of Computer Science Spring 2014: February 24 CS 149: Operating Systems © R. Mak

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.. 0-13-600663-9 All rights reserved Department of Computer Science Spring 2014: February 24 CS 149: Operating Systems © R. Mak

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

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

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.. 0-13-600663-9 All rights reserved Department of Computer Science Spring 2014: February 24 CS 149: Operating Systems © R. Mak

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.. 0-13-600663-9 All rights reserved Department of Computer Science Spring 2014: February 24 CS 149: Operating Systems © R. Mak

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

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

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

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

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

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

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

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

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

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

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

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.. 0-13-600663-9 All rights reserved Department of Computer Science Spring 2014: February 24 CS 149: Operating Systems © R. Mak

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.. 0-13-600663-9 All rights reserved Department of Computer Science Spring 2014: February 24 CS 149: Operating Systems © R. Mak

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