1. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.1 Operating System Concepts Operating Systems Lecture 23 Classic Synchronization Problems

2. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.2 Operating System Concepts The Bounded Buffer Problem Two processes access the same buffer, which is of finite size. The Producer writes to the buffer. The Consumer reads from the buffer. The two processes should not access the buffer at the same time to avoid creating inconsistent data.

3. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.3 Operating System Concepts Bounded-Buffer Problem Assume n buffer slots for data Shared data semaphore full, empty, mutex; Initially: full = 0, empty = n, mutex = 1

4. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.4 Operating System Concepts Bounded-Buffer Problem Producer Process do { … produce an item in nextp … wait(empty); wait(mutex); … add nextp to buffer … signal(mutex); signal(full); } while (1);

5. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.5 Operating System Concepts Bounded-Buffer Problem Consumer Process do { wait(full); wait(mutex); … remove an item from buffer to nextc … signal(mutex); signal(empty); … consume the item in nextc … } while (1);

6. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.6 Operating System Concepts The Readers-Writers Problem Several processes share a buffer for reading and writing. Some processes (readers) only read from the buffer. Some processes (writers) write to the buffer (and may also read). Readers can access the buffer at the same time as other readers without problem. No other processes can be allowed to access the buffer at the same time as a writer, to avoid creating inconsistent data.

7. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.7 Operating System Concepts Readers-Writers Problem Shared data semaphore mutex, wrt; int readcount; Initially mutex = 1, wrt = 1, readcount = 0 Writer's code: wait(wrt); … writing is performed … signal(wrt);

8. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.8 Operating System Concepts Readers-Writers Problem Reader Process wait(mutex); readcount++; if (readcount == 1) wait(wrt); signal(mutex); … reading is performed … wait(mutex); readcount--; if (readcount == 0) signal(wrt); signal(mutex): Questions: Which processes does this favor (readers or writers)? What potential problem does this algorithm have?

9. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.9 Operating System Concepts Dining-Philosophers Problem Philosophers are seated around a table. They alternate thinking and eating. One chopstick is placed in between each pair of philosophers. A philosopher needs the chopsticks on both sides to eat. A philosopher can only pick up one chopstick at a time. We want to guarantee that we don't generate deadlock. We want to guarantee that no philosopher starves.

10. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.10 Operating System Concepts Dining-Philosophers Problem Shared data semaphore chopstick[5]; Initially all values are 1 Philosopher i: do { wait(chopstick[i]); wait(chopstick[(i+1) % 5]); … eat … signal(chopstick[i]); signal(chopstick[(i+1) % 5]); … think … } while (1);

11. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.11 Operating System Concepts Dining-Philosophers Problem Deadlock: If all philosophers decide to eat at the same time and pick up the chopstick on their left. None will be able to pick up a chopstick on their right. Possible Solutions: 1)Allow at most 4 philosophers at the table 2)Allow philosopher to pick up chopsticks only if both available. 3)Odd philosophers pick up left first then right. Even philosophers pick up right first then left. Starvation: A philosopher may never have access to two chopsticks if the philosophers next to him are always eating.

12. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.12 Operating System Concepts Project Description Write a CPU simulator to run scheduling algorithms:  FCFS (first come first serve)  SRTN (shortest remaining time next) Collect statistics:  CPU utilization  Time to execute all processes  Service time  I/O time  Turnaround time for each process

13. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.13 Operating System Concepts Next Event Model Simulation state can change only at event times An event is an occurrence that may change the state of the system.  Process arrival  Change of process state (e.g. interrupt at end of time slice changes process state from running to ready) When an event occurs, the clock is advanced to the next time. An event queue is used to schedule events. Main loop:  Process next event  Perhaps add future events to the queue  Advance the clock

14. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.14 Operating System Concepts Part 1: Writing a Driver The driver should do three things:  Determine which flags have been provided as arguments.  Read in the data from the input file.  Call the function stub for the appropriate scheduling algorithm. Dealing with flags: sim [-d] [-v] [-a algorithm] < input_file Flags will always be in order, but may not all be present. Example: %sim -d < input_file %sim -a FCFS < input_file Note that the input is redirected from a file. How will you read that input in your program?

15. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.15 Operating System Concepts Dealing with flags Use argc to figure out how many flags or arguments Use argv to figure out what they are.  Note: 2 arguments (argc == 3) could mean two flags, -d -v, or one flag and algorithm, -a FCFS. Write the code for this first. Test it extensively.

16. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.16 Operating System Concepts Input Format First line of file: number_processes switch_time Next lines of file: Set of lines for each process:  First line: process_num arrival_time num_CPU_bursts  Next lines: burst_number CPU_time IO_time  Last line: burst_number CPU_time Repeated for each process in input file

17. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.17 Operating System Concepts Sample Input INPUT MEANING 4 5 4 processes, switch_time = 5 1 0 6 Process 1, arrival time 0, 6 bursts 1 15 400 Burst 1, CPU time 15, IO time 400 2 18 200 Burst 2, CPU time 18, IO time 200 3 15 100 4 14 400 5 25 100 6 240 Last burst, no I/O 2 12 4 Process 2, arrival time 12, 4 bursts 1 4 150 2 30 50 3 90 75 4 15...

18. Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, 2005 7.18 Operating System Concepts Things to think about What data structure(s) will you use to store the process information? What parameters need to be passed to the function stubs that will run the schedule simulations? Event Queue: event.cc allows you to get next event and update the time. You can also insert new events in the correct order. How will you build the initial event queue from the process information? Look at event.h, list.h. (We will discuss this more later).