1. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Operating Systems CMPSCI 377 Lecture 7: Synchronization

2. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 2 Last Time: Scheduling Algorithms FCFS First-Come, First-Served Round-robin Use quantum & preemption to alternate jobs SJF Shortest job first Multilevel Feedback Queues Round robin on each priority queue Lottery Scheduling Jobs get tickets Scheduler randomly picks winner

3. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 3 This Time: Synchronization Threads must communicate to ensure consistency Else: race condition (non-deterministic result) Synchronization operations How to write concurrent code How to implement synch. operations

4. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 4 Synchronization – Motivation “The too much milk problem” Model of need to synchronize activities

5. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 5 Synchronization Terminology Mutual exclusion (“mutex”) – prevents multiple threads from entering Critical section – code only one thread can execute at a time Lock – mechanism for mutual exclusion Lock on entering critical section, accessing shared data Unlock when complete Wait if locked

6. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 6 Solving the Too Much Milk Problem Correctness properties Only one person buys milk Safety: “nothing bad happens” Someone buys milk if you need to Progress: “something good eventually happens” First: use atomic loads & stores as building blocks “Leave a note” (lock) “Remove a note” (unlock) “Don’t buy milk if there’s a note” (wait)

7. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 7 Too Much Milk: Solution 1 thread A if (no milk && no note) leave note buy milk remove note thread B if (no milk && no note) leave note buy milk remove note Does this work? too much milk

8. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 8 Too Much Milk: Solution 2 thread A leave note A if (no note B) if (no milk) buy milk remove note A thread B leave note B if (no note A) if (no milk) buy milk remove note B Idea: use labeled notes oops – no milk

9. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 9 Too Much Milk: Solution 3 thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A thread B leave note B if (no note A) if (no milk) buy milk remove note B Idea: wait for the right note Must try all possibilities to verify

10. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 10 Too Much Milk: Solution 3 thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A thread B leave note B if (no note A) if (no milk) buy milk remove note B Possibility 1: A first, then B OK

11. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 11 Too Much Milk: Solution 3 thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A thread B leave note B if (no note A) if (no milk) buy milk remove note B Possibility 2: B first, then A OK

12. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 12 Too Much Milk: Solution 3 thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A thread B leave note B if (no note A) if (no milk) buy milk remove note B Possibility 3: Interleaved – A waits & buys OK

13. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 13 Too Much Milk: Solution 3 thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A thread B leave note B if (no note A) if (no milk) buy milk remove note B Possibility 4: Interleaved – A waits, B buys OK

14. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 14 Too Much Milk: Solution 3 Solution 3: “Thread A waits for B, otherwise buys” Correct – preserves desired properties Safety: we only buy one milk Progress: we always buy milk But…

15. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 15 Problems with this Solution Complicated Difficult to convince ourselves that it works Asymmetrical Threads A & B are different Adding more threads = different code for each thread Poor utilization Busy waiting – consumes CPU resources, no useful work Possibly non-portable Relies on atomicity of loads & stores

16. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 16 Language Support Synchronization complicated Better way – provide language-level support Higher-level approach Hide gory details in runtime system Increasingly high-level approaches: Locks, Atomic Operations Semaphores – generalized locks Monitors – tie shared data to synchronization

17. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 17 Locks Provide mutual exclusion to shared data via two atomic routines Lock::Acquire – wait for lock, then take it Lock::Release – unlock, wake up waiters Rules: Acquire lock before accessing shared data Release lock afterwards Lock – initially released

18. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 18 Too Much Milk: Locks Clean, symmetric - but how do we implement it? thread A Lock.acquire() if (no milk) buy milk Lock.release() thread B Lock.acquire() if (no milk) buy milk Lock.release()

19. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 19 Implementing Locks Requires hardware support (in general) Can build on atomic operations: Load/Store Disable interrupts Uniprocessors only Test & Set, Compare & Swap

20. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 20 Disabling Interrupts Prevent scheduler from switching threads in middle of critical sections Ignores quantum expiration (timer interrupt) No handling I/O operations (Don’t make I/O calls in critical section!) Why not implement as system call?

21. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 21 Implementing Locks: Disabling Interrupts Class Lock { private int value; private Queue q; Lock () { value = 0; q = empty; } public void acquire () { disable interrupts; if (value == BUSY) { add this thread to q; sleep(); } else { value = BUSY; } enable interrupts; } public void release () { disable interrupts; if (q not empty) { thread t = q.pop(); put t on ready queue; } else { value = FREE; } enable interrupts; }

22. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 22 Example: Locks via Disabling Interrupts

23. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 23 Summary Communication between threads: via shared variables Critical sections = regions of code that modify or access shared variables Must be protected by synchronization primitives that ensure mutual exclusion Loads & stores: tricky, error-prone Solution: high-level primitives (e.g., locks)

24. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 24 Next Time More synchronization Semaphores Monitors