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

2. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 2 Semaphores  A semaphore is a shared variable that holds an integer value and has atomic actions: Testing and modifying a semaphore’s value must all be done without interruption. wait(s) { while (s <= 0) block; s--; } signal(s) { s++; }

3. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 3 Semaphores, cont’d  A semaphore that can have any integer value is a counting semaphore. Used to ensure processes that depend on each other will execute in the proper sequence: Statement S2 can only execute after statement S1.  A binary semaphore only has the values 0 or 1. Also called a mutex, to implement mutual exclusion: S1; signal(s); wait(s); S2; wait(m); // lock // execute critical region signal(m); // unlock Just “semaphore” means “counting semaphore”. Just say “mutex” rather than “binary semaphore”.

4. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 4 Example Multithreading Program  Professor Zemma Fore is extremely popular with her students! During each of her office hours, students line up to visit her in order to get help and advice.  Prof. Fore has a small office. Inside, there is room for only one student to visit. Outside her office, there are three chairs for students to sit and wait their turns.

5. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 5 Example Multithreading Program, cont’d  During an office hour: At the start of the hour, Prof. Fore opens her door for office visits. Students arrive at random times. Prof. Fore sees students in the order that they arrive. Each visit with the professor lasts a random time: 1, 2, 3, 4, or 5 minutes.

6. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 6 Example Multithreading Program, cont’d  During an office hour, cont’d: At the end of a visit, the next waiting student (if any) immediately enters Prof. Fore’s office for a visit. Whenever there are no students visiting or waiting, Prof. Fore works on the design of her programming language “ParFore” for her parallel programming class.

7. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 7 Example Multithreading Program, cont’d  Whenever a student arrives: If Prof. Fore is not already meeting with another student, the arriving student can immediately start an office visit. If Prof. Fore is already meeting with another student, the arriving student sits down on an empty chair outside her office to wait. If there are no empty chairs, the student leaves.

8. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 8 Example Multithreading Program, cont’d  At the end of the office hour: If Prof. Fore is not meeting a student, she closes her door and no more students can visit. If she is meeting a student, she allows that visit to complete (which may take her past her closing time) before closing her door. Any students still waiting then leave.

9. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 9 Example Multithreading Program, cont’d  Write a program to simulate students visiting Prof. Fore during one of her office hours. Design your program such that 1 second real time = 1 minute simulated time. Write your program in C using the Pthreads library.

10. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 10 Example Multithreading Program, cont’d  The program should print a message with a timestamp as each event occurs. Events: student arrives, student starts office visit, etc. The output should be in a tabular format that shows the state changes of the components of your simulation. Will Prof. Fore ever find time to work on her language ParFore the course? Demo

11. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak Example Multithreading Program, cont’d  The program contains a subtle threading bug! Causes a deadlock under certain circumstances. Can you find the error and correct it? 11

12. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 12 Assignment #3  Create a multithreaded simulation of students enrolling into three sections of CS 149. Simulate each student with a thread.  Three types of students: Graduating seniors (GS) have highest priority. “Regular” seniors (RS) Everyone else (EE) have lowest priority.

13. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak Assignment #3, cont’d  75 students arrive for enrollment at random times spread over 2 minutes of real time. Arrival times are whole seconds.  For each student: Assign a unique id. Randomly be GS, RS, or EE with equal probability. Can enroll only into Section 1, Section 2, Section 3, or any section with equal probability. 13

14. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak Assignment #3, cont’d  Three queues: GS queue, RS queue, EE queue Each arriving student enters the appropriate queue. Students leave at the heads of the queues to be enrolled into a section.  The queues work simultaneously. Each queue can process and enroll only one student at a time. GS queue: randomly 1 or 2 seconds to process RS queue: randomly 2, 3, or 4 seconds to process EE queue: randomly 3, 4, 5, or 6 seconds to process Compute a new process time for each student. 14

15. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak Assignment #3, cont’d  Each CS 149 section has a max capacity of 20. Drop any student who cannot enroll after processing. Process the next student in the queue.  The simulation finishes when All 75 students have been processed, or All three sections are full. 15

16. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak Assignment #3, cont’d  Print a line for each event as it occurs: A student arrives and enters a queue. A queue starts to process a student. A queue finishes processing a student and then either drops or enrolls the student into a section.  Timestamp each event print line. Minutes and seconds, such as 0:05 and 1:12 The simulation starts at time 0:00.  Identify a student by id and type, such as #12.GS 16

17. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak Assignment #3, cont’d  At the end of the simulation, print: Who is enrolled in each section of CS 149. What was the turnaround time for each student (from arrival time to being enrolled or dropped). The average turnaround time of each queue. Who could not enroll and was dropped. Any other statistics you find interesting.  Tips What threads besides student threads? What are the critical regions? What process synchronization is necessary? 17

18. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak Assignment #3, cont’d  Extra credit (up to 10 points): Impatient students give up and leave after waiting 10 seconds in a queue before being processed. At the end of the simulation, print the number of students who gave up and left.  Turn in a zip file named after your team: C source files Text file containing output from a simulation run. 1 or 2 page report on your software design. What threads? What shared data and critical regions? What synchronization? 18 Note clearly if you did the extra credit.

19. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 19 Assignment #3, cont’d  Subject line: CS 149- section Assignment #3 team name CC all team members.  Due Friday, February 27.

20. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 20 Readers-Writers Problem  Suppose that a file is a shared resource among multiple processes. It is permissible for multiple processes to be reading the file at the same time. But if one process is writing to the file, no other process (reader or writer) can access the file.  Can we use semaphores and mutexes to solve this problem?

21. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 21 Readers-Writers Problem, cont’d  If no processes are currently accessing the file, then either a reader process or a writer process can start to access the file.  If a writer process starts to access the file: It must prevent any other reader or writer process from accessing the file until it’s done.  If a reader process starts to access the file: It should allow other reader processes to access the file. It should prevent a writer process from accessing the file.

22. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 22 Readers-Writers Problem, cont’d  Use semaphore rw_sem to keep other processes from accessing the file.  The writer process must always wait on rw_sem. A writer process blocks another writer process. A reader process blocks any writer process.

23. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 23 Readers-Writers Problem, cont’d  The first reader process to access the file must wait on rw_sem Force any writer processes to wait.  However, subsequent reader processes don’t have to wait. Multiple readers can read the file at the same time.  The last reader process to complete its access of the file must signal the semaphore. Let in any waiting writer process.

24. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 24 Readers-Writers Problem, cont’d  Therefore, we must keep a count of how many reader processes are currently accessing the file. If the count > 0, then a writer process can’t access the file.

25. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 25 Readers-Writers Problem, cont’d  Writer process: Semaphore rw_sem = 1; // one shared resource (the file) void writer(void) { for (;;) { wait(&rw_sem); // keep out all other processes... // write to the file signal(&rw_sem); // let in a waiting process } } Pseudocode

26. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 26 Readers-Writers Problem, cont’d  Reader process: int count = 0; // count of reader processes void reader(void) { for (;;) { count++; if (count == 1) { // the first reader only wait(&rw_sem); // keeps out writers }... // read the file count--; if (count == 0) { // the last reader only signal(&rw_sem); // lets in a waiting writer } } } What is wrong with this code? We have a race condition with shared variable count. Pseudocode

27. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 27 Readers-Writers Problem, cont’d  We have a race condition with variable count.  Therefore, any reader code that accesses count should be a critical region. Use a mutex to enforce the mutual exclusion.

28. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 28 Readers-Writers Problem, cont’d  Reader processes (corrected): int count = 0; // count of reader processes Mutex mutex = 1; void reader(void) { for (;;) { lock(&mutex); // start critical region count++; if (count == 1) { // first reader only wait(&rw_sem); // keep out writers } unlock(&mutex); // end critical region... // read the file lock(&mutex); // start critical region count--; if (count == 0) { // last reader only signal(&rw_sem); // let in a waiting writer } unlock(&mutex); // end critical region } } Pseudocode

29. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 29 Dining Philosophers Problem  Five philosophers are seated at a round table. Each philosopher has a plate of spaghetti. There is a single fork between each plate.  A philosopher alternates between thinking and eating. In order to eat spaghetti, a philosopher must obtain both the left and the right fork.

30. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 30 Dining Philosophers Problem, cont’d  Lunchtime in SJSU’s Department of Philosophy. Operating Systems: Design and Implementation Tanenbaum & Woodhull (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8

31. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 31 Dining Philosophers Problem  How can we enable all the philosophers to eat with the shared forks?  Concurrency-control problem: How to allocate limited resources among competing processes. No deadlocks No starvation (in the process sense)

32. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 32 Dining Philosophers Problem, cont’d  Why won’t this work? What if each philosopher simultaneously picks up the left fork? Starvation!  A possible fix: After failing to get a fork, wait a random amount of time and try again.  Is there a solution that doesn’t involve retries? #define N 5 void dine(int id) { int left = id; int right = (id+1)%N; for (;;) { think(); take_fork(left); take_fork(right); eat(); release_fork(left); release_fork(right); } }

33. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 33 Dining Philosophers Problem: A Solution  Since the forks are a shared resource, the dining code that accesses forks are a critical region.  Therefore, use a mutex to enforce mutual exclusion. Lock the mutex before taking the forks. Unlock the mutex after releasing the forks. for (;;) { think(); lock(&mutex); take_fork(left); take_fork(right); eat(); release_fork(left); release_fork(right); unlock(&mutex); }

34. Computer Science Dept. Spring 2015: February 17 CS 149: Operating Systems © R. Mak 34 Dining Philosophers: A Solution, cont’d  Problems? Only one philosopher can eat at a time! for (;;) { think(); lock(&mutex); take_fork(left); take_fork(right); eat(); release_fork(left); release_fork(right); unlock(&mutex); }