1. 11/18/20151 Operating Systems Design (CS 423) Elsa L Gunter 2112 SC, UIUC http://www.cs.illinois.edu/class/cs423/ Based on slides by Roy Campbell, Sam King, and Andrew S Tanenbaum

2. Synchronizing multiple threads Must control interleaving between threads Order of some operations irrelevant Independent Other operations are dependent and order does matter All possible interleaving must yield a correct answer A correct concurrent program will work no matter how fast the processors are that execute the various threads 11/18/20152

3. Synchronizing multiple threads All interleavings result in correct answer Try to constrain the thread executions as little as possible Controlling the execution and order of threads is called “synchronization” 11/18/20153

4. Too much milk The Gunter household drinks a lot of milk, but has a small fridge Problem: Carl and Elsa want there to always at least one gallon of milk in the fridge for dinner; fridge holds at most two gallons If either sees there is less than one gallon, goes to buy milk Specification: Someone buys milk if running low Never more than two gallons of milk milk 11/18/20154

5. Solution #0 – no sync Carl Elsa 5:30 Comes home 5:35 Checks milk 5:40 Goes to store 5:45Comes home 5:50 Buys milkChecks milk 5:55 Goes homeGoes to store 6:00 Puts milk in Fridge Buys milk 6:05Comes home 6:10Too much milk! 11/18/20155

6. Mutual Exclusion Ensure that only 1 thread is doing a certain thing at one time Only one person goes shopping at one time Critical section A section of code that needs to run atomically w.r.t. other code If code A and code B are critical sections w.r.t. each other threads cannot interleave events from A and B Critical sections must be atomic w.r.t. each other Share data (or other resourced, e.g., screen, fridge) What is the critical section in solution #0? 11/18/20156

7. Too much milk (solution #1) Assume only atomic operations are load and store Idea: leave note that going to check on milk status Carl: if (no note) {if (milk low) {leave note; buy milk; remove note;} Elsa: if (no note) {if (milk low) {leave note; buy milk; remove note;} What can go wrong? Is this better than before? 11/18/20157

8. Too much milk (solution #2) Idea: Change order of leave note and check milk Carl: if (milk low) {if (no note) {leave note; buy milk; remove note;} Elsa: if (milk low) {if (no note) {leave note; buy milk; remove note;} What can go wrong? Is this better than before? 11/18/20158

9. Too much milk (solution #3) Idea: Protect more actions with note Carl: if (no note) {leave note; if (milk low) {buy milk}; remove note;} Elsa: if (no note) {leave note; if (milk low) {buy milk}; remove note;} What can go wrong? Is this better than before? 11/18/20159

10. Too much milk (solution #4) Idea: Change order of leaving note and checking note Carl: leave noteCarl; if (no noteElsa) { if (milk low) {buy milk};} ; remove noteCarl Elsa: leave noteElsa; if (no noteCarl) { if (milk low) {buy milk};} ; remove noteElsa What can go wrong? Is this better than before? 11/18/201510

11. Too much milk (solution #5) Idea: When both leave note, always give priority to fixed one to buy milk Carl: leave noteCarl; while (noteElsa) {do nothing}; if (milk low) {buy milk}; remove noteCarl Elsa: leave noteElsa; if (no noteCarl) { if (milk low) {buy milk};} ; remove noteElsa Simplified instance of Bakery Algorithm 11/18/201511

12. Too much milk (solution #5) while (noteElsa) for Carl prevents him from buying milk at same time as Elsa Proof of correctness Two parts: Will never have two people buying milk at same time Will always have someone able to buy milk if it is needed Correct, but ugly Complicated, Asymmetric, Inefficient Carl wastes time while waiting (Busy Waiting) 11/18/201512

13. Higher-level synchronization Problem: could solve “too much milk” using atomic loads/stores, but messy Solution: raise the level of abstraction to make life easier for the programmer 11/18/201513 Concurrent programs High-level synchronization provided by software Low-level atomic operations provided by hardware

14. Locks (mutexes) A lock is used to prevent another thread from entering a critical section Two operations Lock(): wait until lock is free, then acquire do {if (lock == LOCK_FREE) { lock = LOCK_SET; break;} } while(1) Unlock(): lock = LOCK_FREE 11/18/201514

15. Locks (mutexes) Why was the “note” in Too Much Milk solutions #1 and #2 not a good lock? Four elements of using locks Lock is initialized to be free Acquire lock before entering a critical section Wait to acquire lock if another thread already holds Release lock after exiting critical section All synchronization involves waiting Thread can be running, or blocked (waiting) 11/18/201515

16. Locks Locks -- shared variable among all thread Multiple threads share locks Only affects threads that try to acquire locks Important: Lock acquisition is atomic! 11/18/201516

17. Lock Variables Critical section -- part of the program where threads access shared (global) state Locks -- shared variables used to enforce mutual exclusion Can have multiple lock variables 11/18/201517

18. Locks (mutexes) Locks make “Too Much Milk” really easy to solve! Correct but inefficient How to reduce waiting for lock? How to reduce time lock is held? 11/18/201518 Elsa: lock(frigdelock); if (milk low) {buy milk} unlock(fridgelock) Carl: lock(frigdelock); if (milk low) {buy milk} unlock(fridgelock)

19. Too Much Milk – Solution 7 Does the following work? lock(); if (milk low & no note) { leave note; unlock(); buy milk; remove note; } else { unlock() } 11/18/201519

20. Too Much Milk – Solution 7 Does the following work? lock(); if (milk low & no note) { leave note; unlock(); buy milk; lock(); remove note; unlock(); } else { unlock() } 11/18/201520

21. Queues without Locks enqueue (new_element, head) { // find tail of queue for(ptr=head; ptr->next != NULL; ptr = ptr->next); // add new element to tail ptr->next = new_element; new_element->next = NULL; } 11/18/201521

22. Queues without Locks dequeue(head, element) { element = NULL; // if something on queue, remove it if(head->next != NULL) { element = head->next; head->next = head->next->next;} return element; } What bad things can happen if two threads manipulate the queue at the same time? 11/18/201522

23. Thread-safe Queues with Locks enqueue (new_elt, head) { lock(queuelock); // find tail of queue for(ptr=head; ptr->next != NULL; ptr = ptr->next); // add new element to tail ptr->next = new_elt; new_elt->next = NULL; unlock(queuelock); } dequeue(head, elt) { lock(queuelock); element = NULL; // remove if possible if(head->next != NULL) { elt = head->next; head->next = head->next->next;} unlock(queuelock); return elt; } 11/18/201523

24. Invariants for multi-threaded queue Can enqueue() unlock anywhere? Stable state called an invariant I.e., something that is “always” true Is the invariant ever allowed to be false? 11/18/201524

25. Invariants for multi-threaded queue In general, must hold lock when manipulating shared data What if you’re only reading shared data? 11/18/201525

26. Enqueue – Can we do better? enqueue() { lock find tail of queue unlock lock add new element to tail of queue unlock } Is this better? 11/18/201526

27. Dequeue if empty? What if you wanted to have dequeue() wait if the queue is empty? Could spin in a loop: dequeue() { lock(queuelock); element = NULL; while (head-next == NULL) {wait;}; if(head->next != NULL) { element = head->next; head->next = head->next->next;} unlock(queuelock); return element; } 11/18/201527

28. Problem lock(queuelock); … while (head-next == NULL) {wait;}; Holding lock while waiting No one else can access list (if they observe the lock) Wait forever 11/18/201528

29. Dequeue if empty – Try 2 Could release the lock before spinning: lock(queuelock); … unlock(queuelock); while (head-next == NULL) {wait;}; Will this work? 11/18/201529

30. Dequeue if empty – Try 3 Could release lock and acquire lock on every iteration lock(queuelock); … while (head-next == NULL) {unlock(queuelock); lock(queuelock);}; This will work, but very ineffecient. 11/18/201530