1. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Computer Systems Principles Synchronization Emery Berger and Mark Corner University of Massachusetts Amherst

2. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 2 Synchronization  Threads must ensure consistency –Else: race condition (non-deterministic result) –Requires synchronization operations  How to write concurrent code  How to implement synch. operations

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

4. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 4 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 entering critical section, accessing shared data –Unlock when complete –Wait if locked  Invariant –Something that must be true when not holding lock

5. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 5 Solving Too Much Milk  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)

6. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 6 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 Too Much Milk: Solution 1

7. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 7 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 Too Much Milk: Solution 2

8. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 8 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 Quick Activity: does this work? Too Much Milk: Solution 3

9. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 9 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 Too Much Milk: Solution 3

10. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 10 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 Too Much Milk: Solution 3

11. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 11 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 Too Much Milk: Solution 3

12. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 12 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 Too Much Milk: Solution 3

13. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 13 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…

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

15. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 15 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

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

17. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Locks and Queuing  Acquire: –if unlocked, go in; otherwise wait in line  Release: –Unlock & leave 17

18. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 18 Pthreads Syntax  POSIX standard for C/C++  Mutual exclusion locks –Ensures only one thread in critical section pthread_mutex_init (&l); … pthread_mutex_lock (&l); update data; /* critical section */ pthread_mutex_unlock (&l);

19. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 19 thread Athread B Too Much Milk: Locks

20. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 20 thread A p_m_lock(&l) if (no milk) buy milk p_m_unlock(&l) thread B p_m_lock(&l) if (no milk) buy milk p_m_unlock(&l) Too Much Milk: Locks  Clean, symmetric  How do we implement it?

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

22. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 22 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?

23. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 23 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; enable interrupts; sleep(); } else { value = BUSY; } enable interrupts; } public void release () { disable interrupts; if (q not empty) { thread t = q.pop(); put t on ready queue; } value = FREE; enable interrupts; } Disabling Interrupts

24. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 24 Locks via Disabling Interrupts

25. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 25 Summary  Communication between threads –via shared variables  Critical sections –regions of code that 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)

26. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 26 The End

27. U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science 27 Pthreads API