1. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington1 Synchronization Part 1 CSE 410, Spring 2008 Computer Systems http://www.cs.washington.edu/410

2. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington2 Readings and References Reading »Chapter 6, Operating System Concepts, Silberschatz, Galvin, and Gagne. Read the following sections: 6.1, 6.2, 6.3 Other References »Chapter 6, Multithreaded Programming with Pthreads, First edition, Bil Lewis and Daniel J. Berg, Sun Microsystems Press »Sections 5.8.3, Atomicity and Atomic Changes, 5.8.4, Critical Regions with Interrupts Enabled, See MIPS Run, Dominic Sweetman

3. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington3 Story of the Oracle Concurrent data access is complex »The solutions presented in this chapter are a great start »Individually each have advantages and disadvantages, and can be used in conjunction It all happened one day in a microchip garden…

4. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington4 Too Much Milk Arrive home; put milk away Oh no, too much milk! 3:30 Buy milk3:25 Arrive at storeArrive home; put milk away3:20 Leave for storeBuy milk3:15 Look in fridge; no milkArrive at store3:10 Leave for store3:05 Look in fridge; no milk3:00 Your RoommateYou

5. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington5 Modeling the Problem Model you and your roommate as threads “Looking in the fridge” and “putting away milk” are reading/writing a variable YOU: // look in fridge if( milkAmount == 0 ) { // buy milk milkAmount++; } YOUR ROOMMATE: // look in fridge if( milkAmount == 0 ) { // buy milk milkAmount++; }

6. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington6 Correctness Properties Decomposed into safety and liveness »safety the program never does anything bad (mutual exclusion) »liveness the program eventually does something good (progress and bounded waiting) Although easy to state, these properties are not always easy to meet (or prove!)

7. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington7 Synchronization Definitions Synchronization »coordinated access by more than one thread to shared state variables Mutual Exclusion »only one thread does a particular thing at a time. One thread doing it excludes all others. Critical Section »only one thread executes in a critical section at once

8. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington8 Critical Section Problem How to share data amongst n threads in an orderly and efficient fashion Must guarantee: »Mutual Exclusion »Progress (no deadlocks, no infinite waiting) »Bounded Waiting (a bound exists on the number of times you are skipped post request)

9. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington9 Locks A lock provides mutual exclusion »Only one thread can hold the lock at a time »A lock is also called a mutex (for mutual exclusion) Thread must acquire the lock before entering a critical section of code Thread releases the lock after it leaves the critical section

10. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington10 Too Much Milk: A Solution YOU: MilkLock->Acquire(); if( milkAmount == 0 ){ // buy milk milkAmount++; } MilkLock->Release(); YOUR ROOMMATE: MilkLock->Acquire(); delay if( milkAmount == 0 ){ // buy milk milkAmount++; } MilkLock->Release();

11. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington11 Lock Implementation Issue A context switch can happen at any time »very simple acquire/release functions don’t work »in this case, both threads think they set lockInUse Lock::Acquire() { while( lockInUse ) {} lockInUse = true; } Lock::Release() { lockInUse = false; } Lock::Acquire() { while( lockInUse ) {} lockInUse = true; }

12. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington12 Disable interrupts during critical section disable interrupts to prevent a context switch »simple but imperfect solution Lock::Acquire() { disable interrupts; } Lock::Release() { enable interrupts; } Kernel can’t get control when interrupts disabled Critical sections may be long »turning off interrupts for a long time is very bad Turning off interrupts is difficult and costly in multiprocessor systems

13. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington13 Disable Interrupts with flag Only disable interrupts when updating a lock flag Lock::Release() { disable interrupts; value = FREE; enable interrupts; } initialize value = FREE; Lock::Acquire() { disable interrupts; while(value != FREE){ enable interrupts; disable interrupts; } value = BUSY; enable interrupts }

14. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington14 Atomic Operations An atomic operation is an operation that cannot be interrupted On a multiprocessor disabling interrupts doesn’t work well Modern processors provide atomic read- modify-write instruction or equivalent These instructions allow locks to be implemented on a multiprocessor

15. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington15 Examples of Atomic Instructions Test and set (many architectures) »sets a memory location to 1 and returns the previous value »if result is 1, lock was already taken, keep trying »if result is 0, you are the one who set it so you’ve got the lock Exchange (x86) »swaps value between register and memory Compare & swap (68000) read location value if location value equals comparison value store update value, set flag true else set flag false

16. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington16 Busy Waiting CPU cycles are consumed while the thread is waiting for value to become 0 This is very inefficient Big problem if the thread that is waiting has a higher priority than the thread that holds the lock

17. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington17 Spinlocks are Semaphores Used in XP, Solaris, Linux… If( sleeping + context switch < spinning for hundreds of cycles) then sleep(); else spin(); »In MP environment, this can be of use when the first if condition is false If uniprocessor then sleep() else spin();

18. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington18 Locks with Minimal Busy Waiting Use a queue for threads waiting on the lock A guard variable provides mutual exclusion Lock::Release() { while(TestAndSet(guard){} if(anyone on wait queue){ move thread from wait queue to ready queue; } else { value = FREE; } guard = 0; } Lock::Acquire() { while(TestAndSet(guard)){} if( value != FREE ) { Put self on wait queue; guard = 0 and switch(); } else { value = BUSY; guard = 0; }

19. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington19 Synchronization Summary Threads often work independently But sometimes threads need to access shared data Access to shared data must be mutually exclusive to ensure safety and liveness Locks are a good way to provide mutual exclusion

20. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington20 Dojo-Enabled Morpheous “Is it real?”

21. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington21 Problems Sleeping Barber Dying Philosophers Traveling Salesman

22. Problems Nash Equilibrium Talking Morpheous Bounded-Buffer Problem 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington22

23. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington23 Terms Process Synchronization Mutual Exclusion Non-preemptive Scheduling Preemptive Scheduling Non-preemptive Kernel Preemptive Kernel

24. Terms Race Conditions V.S. Race Cars in Forza 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington24

25. Terms Critical Section VS Critical Hit 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington25

26. Terms Process Synchronization V.S. Shared Memory Chaos 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington26

27. Terms Non-preemptive Scheduling V.S. Preemptive Scheduling 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington27

28. Terms Non-preemptive Kernel V.S. Preemptive Kernels 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington28

29. Terms Spinlocks on uniprocessors V.S. Spinlocks on SMP systems 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington29

30. Terms Atomicity V.S. Mutual Exclusion 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington30

31. Terms Critical Section Solution Requirements V.S. Critically Acclaimed: Daft Punk 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington31

32. Terms Spinlocks on single processors V.S. Spinlocks on multi-processors 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington32

33. Terms Disabling interrupts in a uniprocessor V.S. Disabling interrupts in a SMP system 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington33

34. Terms Semaphore V.S. Smore 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington34

35. Block Locking Beats Spinlocks V.S. Block[ing] locks 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington35

36. Deadlock: waiting for a call that will never come Deadlock via wait calls V.S. Deadlock via resource acquisition 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington36

37. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington37 Think and ponder…

38. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington38 Terms2 Peterson’s solution Nonpreemptive uniprocessor Locks Flux capacitor Semaphores Mutex Mutant Ninja Turtles Dreadlocks Deadlock

39. 9/8/2015cse410-23-synchronization-p1 © 2006-07 Perkins DW Johnson and University of Washington39 Now you know…