11/18/20151 Operating Systems Design (CS 423) Elsa L Gunter 2112 SC, UIUC Based on slides by Roy Campbell, Sam King, and Andrew S Tanenbaum

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

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

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

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

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

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

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

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

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

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

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

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/ Concurrent programs High-level synchronization provided by software Low-level atomic operations provided by hardware

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

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

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

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

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/ Elsa: lock(frigdelock); if (milk low) {buy milk} unlock(fridgelock) Carl: lock(frigdelock); if (milk low) {buy milk} unlock(fridgelock)

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

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

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

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

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

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

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

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

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

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

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

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