COMP 3430 Robert Guderian

Transcription

1 Operating Systems COMP 3430 Robert Guderian file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 1/76 1

2 Concurrency file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 2/76 2

3 Last week IPC signals, FIFOs Scheduling file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 3/76 3

4 This week Concurrent processes Relevant chapters: Chapter Chapter 30, 31 file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 4/76 4

5 Concurrency Definition: two or more events or circumstances happening or existing at the same time In CS: Running many processes and threads at the same time, and achieving a deterministic result We've seen this with threads already file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 5/76 5

6 Concurrency This week: Formalize concurrent data access, and concurrent resources See algorithms to control access file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 6/76 6

7 Threads Good tools to synchronize data Threads know about each other, share codebases! Buuuuuuut... file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 7/76 7

8 Processes Processes might not know about each other Two or more processes may require the same system resource These processes might not know about each other They don't share a codebase file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 8/76 8

9 Synchronizing processes How can we resolve this problem? IPC! Abstraction: all resources are memory, need to control access to the memory file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 9/76 9

10 Goals Processes must share access to a resource Must serialize access to the shared resource This is just locking - serial means one-at-a-time Mutex! Access to shared resources must be atomic All or nothing file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 10/76 10

11 Critical sections The resource that must be protected is a critical resource. The code that processes the resource is a critical section. file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 11/76 11

12 Locking problems First problem: deadlock Consider: Two processes require two locks to do their tasks... But, each one holds one of the locks file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 12/76 12

13 Locking problems Second: starvation A process greedily holding a lock "I'm going to use this again, so why unlock" - everything else waits. file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 13/76 13

14 How to make a lock How can we solve this problem? Iterate on ideas on how to build a lock... file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 14/76 14

15 Lock attempt 1 Assume we have 2 well-known processes accessing some critical resource. Have them take turns? file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 15/76 15

16 Lock attempt 1 Pass the lock // process id 0 while(turn!= 0) {/*nothing*/} // have the lock // so something // done critical section, pass the lock to the next process turn = 1; file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 16/76 16

17 Lock attempt 1 Did we do it? Mutex? Yes! Does it scale? no... Does it always work? What if a process crashes? Starvation! file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 17/76 17

18 Lock attempt 2 Concept: have an array of bool, one entry for each process More scalable! If any element is true, that process has the lock file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 18/76 18

19 Lock attempt 2 while (locks[1]) // other thread has the lock {/*zzzz*/} locks[0] = true; // take the lock // critical section - do work // CS done, pass the lock locks[0] = false; //free the lock file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 19/76 19

20 What could possibly go wrong? What happens if a context switch happens just before locks[0] = true; file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 20/76 20

21 Lock attempt 2 Mutex? No. The problem? Setting our flag AFTER checking their flag file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 21/76 21

22 Lock attempt 3 Try setting our flag before we check their flag Then, if we have the lock we have the lock Otherwise, leave our flag, and wait for their flag to clear flag[0] = true; while (flag[1]) {} // we have the lock! // Done CS, free lock: flag[0] = false; file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 22/76 22

23 Lock attempt 3 Mutex? Yes! Are we problem-free? What about deadlock? We're greedily holding any locks we already have Not atomic (grab some locks, not all, deadlock) file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 23/76 23

24 Lock attempt 4 If we fail getting the lock, give up the lock, sleep How? file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 24/76 24

25 Lock attempt 4 flag[0] = true; while(flag[1]){ flag[0] = false; // give up lock sleep(1); flag[0] = true; // try again! } // have lock flag[0] = false; file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 25/76 25

26 Lock attempt 4 How did we do? Mutex? Yes! Deadlock?... no? Livelock? Both try lock, both sleep 1s, both try lock, both sleep 1s... file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 26/76 26

27 Livelock Both processes are collect some of their locks, get block, sleep - in perfect synchronicity. Think: to shopping carts in an aisle of a store. Solution? Random sleep times - better, but not a guarantee. file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 27/76 27

28 Dekker's Algorithm Avoid deadlock by mixing all these ideas, including the concept of a turn! Process gets the lock, and waits for turn file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 28/76 28

29 Dekker psuedocode For task x flag[x] = true; while (flag[!x]) if (turn!= x) flag[x] = false; while (turn[!x]); flag[x] = true; // Got the lock! turn =!x; flag[x]=false; file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 29/76 29

30 Peterson's Algorithm A simplification on Dekker's: flag[x] = true turn!= x while (flag[!x] && turn!= x); // lock flag[x] = false file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 30/76 30

31 Peterson How does the while work? What if both processes set their flag at the same time? Turn choses who can go Turn is only used if both have their flag set file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 31/76 31

32 There's got to be a better way This is hard. And weird. Examples assumed 2 (or a known number of) processes. These are software solutions, called spinlocks. Hardware has evolved to help with these problems. file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 32/76 32

33 Hardware mutex The kernel + processor let us write a word atomically. A few different implementations: TAS Test-And-Set (e.g. Motorola 68000) CAS Compare-And-Swap (e.g. IBM 370 and Motorola 68000) XCHG exchange (e.g. x86) *LL/SC Load Linked and Store Conditional (e.g. MIPS & ARM) file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 33/76 33

34 Test-and-set (TAS) Remember, we can write atomically now! The pseudocode is: bool testandset(int n) { if (n==0) { // no flag n = 1 return true } return false } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 34/76 34

35 Test-and-set (TAS) int lock = 0; // lots of code... while (!testandset(getpid())); // have lock lock = 0; Now, in our code Does it matter how many processes are accessing this lock? No! Problems What if process doesn't free the lock? Still a spinlock file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 35/76 35

36 Compare-and-swap (CAS) The same idea Shared memory that we read & write to atomically Check for a value (probably 0, indicating lock is free), set value if the value is what we expected Difference: we send the expected value file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 36/76 36

37 Compare-and-swap (CAS) Psuedocode: bool CAS(int* test, int old, int new){ if (*test == old){ *test = new; return true; } return false; } (Some return the old value on success) file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 37/76 37

38 Compare-and-swap (CAS) How do we use it? int lock = 0; // lots of code... while (!compareandswap(&lock, 0, 1)); // have lock compareandswap(&lock, 1, 0) file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 38/76 38

39 CAS and TAS Are they good? Advantages: Any * of tasks Simple operation Atomic, handled by hardware file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 39/76 39

40 CAS and TAS But... Still a spinlock Starvation and Deadlock still possible - left up to programmers... Can we really trust programmers? Can we do better? file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 40/76 40

41 Have the OS deal with locks The OS can act as a broker for locks Using semaphores! What? Oxford,... what? [Traffic semaphore] ( A signaling system! file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 41/76 41

42 Semaphores Mutex is one use of the things it can do. Two types of semaphores: 1. Counting semaphore - allows n processes access to a critical resource. 2. 0/1 semaphore (binary semaphore) - only counts to 1... mutex! file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 42/76 42

43 Semaphores 3 operations: 1. initialize: initialize with a non-zero number the # of concurrent tasks that can access 2. wait: decrement the value of the semaphore, block if the value is negative 3. signal: increment the value if value <= 0, unblock a waiting task. if >= 0, there's no waiting tasks! file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 43/76 43

44 Semaphores - queues Semaphore needs a queue to hold blocked tasks. 2 models: 1. dequeue in any order Weak or asynchronous 2. queue tasks as FIFO Forces an order, potentially reduces concurrency (livelocks) file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 44/76 44

45 psuedo-semaphore Just a count, and a queue of blocked processes struct{ int count; queue Q; } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 45/76 45

46 psuedo-sema Wait function - remember, this is an OS-level function, so we can control the state of processes! wait (sema s) { s.count--; if (s.count < 0 ) // not available s.q.enter(task); block(task); // block this thread } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 46/76 46

47 psuedo-sema Signal function - someone freed the lock signal(sema s) { s.count++; if (s.count < 0) // is a prc waiting? s.q.leave() ready(task) // put on ready queue } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 47/76 47

48 pseudo-sema What code has to be atomic? Everything except setting the state of the process. file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 48/76 48

49 pseudo-use sema lock; lock.init(); lock.wait(); // critical section lock.signal(); file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 49/76 49

50 OS concepts The operating system manages resources, we abstract the resources to producers and consumers Producers make data for consumption/resources for use Consumers take data (process data)/use resources Called "Producer/Consumer model" file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 50/76 50

51 Producer/Consumer Problem 1 or more producers creating data/resources 1 or more consumers taking data/resources consumer can not read from an empty buffer file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 51/76 51

52 The bounded buffer Producer/consumers use a bounded buffer to share their data - FIFO queue on an array. Producers write to the 'in' pointer Consumers write to the 'out' pointer file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 52/76 52

53 Producer/consumer Producer pseudocode void produce(){ v = getnewdata(); buffer[in] = v; in++; } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 53/76 53

54 Producer/consumer Consumer pseudocode int consume(){ while (in <= out) {}; x = buffer[out++]; return x; } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 54/76 54

55 Locking? Of course Can't have two consume at the same time! But how? file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 55/76 55

56 Mutex Attempt 1: Lock the whole thing Lock the entire buffer - in, and out Works, but serializes all input/output "course grain" locking file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 56/76 56

57 Mutex Attempt 2: Use a semaphore Hey, we just learned about that, this is such a big surprise Has signalling, gets rid of busy wait How should we use it? file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 57/76 57

58 Semaphore solution v1 Use it as a mutex lock - producer sema lock; void produce(){ v = getnewdata(); lock.wait() buffer[in] = v; in++; lock.signal(); } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 58/76 58

59 Semaphore solution v1 int consume(){ lock.wait(); x = buffer[out++]; lock.signal(); return x; } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 59/76 59

60 Semaphore solution v1 Is it good? Mutex? Yes! It still agressively a mutex? Yes! Do we need to lock the buffer? No! file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 60/76 60

61 Semaphore solution v2 Use 2 locks, one for the buffer, one for consuming sema lock; sema numdata; void produce(){ v = getnewdata(); lock.wait() buffer[in] = v; in++; lock.signal(); numdata.signal(); } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 61/76 61

62 Semaphore solution v2 int consume(){ numdata.wait(); x = buffer[out++]; return x; } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 62/76 62

63 Semaphore solution v2 Mutex? Yes Cool? Yes! Problems? Finite buffer, could get filled. Solvable with more locks (of course) file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 63/76 63

64 Semaphore solution v3 What about... producer... sema inlock; void produce(){ v = getnewdata(); inlock.wait() buffer[in] = v; in++; inlock.signal(); } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 64/76 64

65 Semaphore solution v3 Consumer... sema outlock; int consume(){ outlock.wait(); x = buffer[out++]; outlock.signal(); return x; } file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 65/76 65

66 Semaphore solution v3 Mutex? Yes Aggressive locking? No file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 66/76 66

67 Bounded buffer wrap-up Interesting problem, because there is many solutions, most have tradeoffs. file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 67/76 67

68 Deadlock Deadlock - threads/processes blocking each other Can we be more formal What are the causes How do we avoid them? file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 68/76 68

69 Conditions 4 conditions for deadlock Mutual exclusion Hold-and-wait No preemption Circular wait Prevent ONE, and no deadlock can occur file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 69/76 69

70 Prevent mutex lock Ask youself some questions Lock smaller elements? Does THIS need to be locked? Does this NEED to be locked? Is there a lock-free solution? Replace with CAS? file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 70/76 70

71 Prevent hold-and-wait Get all locks at once, atomically If we can't get them all, give them all up. Sleep, hoping they will become available Terrible, but easy Or, list up-front what we need, don't wake until all locks are available Unrealistic! file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 71/76 71

72 Prevent "no preemption" Allow preemption! Take locks away from deadlocked processes... How do we preempt a process that is holding a lock? It's unsafe! pthread_mutex_trylock - don't have to be prempted! file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 72/76 72

73 Prevent circular wait This is where we can be clever! This is preventing livelock. Can we... Always lock in a certain order? ALWAYS lock L1, then L2, would never have L2 locked without L1 Called Partial ordering Draw the resource dependency graph file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 73/76 73

74 Other deadlock avoidance Scheduling: Never schedule P1 and P2 at the same time (multi- CPU) Clean up locks before context switch Wait, we can't control that file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 74/76 74

75 Other deadlock avoidance Detect and Recover - This is real-world Use an outside process to monitor for deadlocks If all processes are blocked, kill one Or, send a signal (SIGUSR1?) which tells one process to drop locks? file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 75/76 75

76 Concurrency, conclusion Locks are difficult to make Deadlock is hard to avoid Resources are hard to manage The OS manages locks, to aide with concurrency file:///users/robg/dropbox/teaching/ /slides/06_concurrency/index.html?print-pdf#/ 76/76 76