COMP 111 Threads and concurrency Sept 28 2005

COMP 111 Threads and concurrency Sept 28, 2005

Who is this guy? l I am not Prof. Couch Obvious? l Sam Guyer l l New assistant professor in CS Complete Ph. D. in 2003 at University of Texas Grew up in Boston Research area: Compilers Mostly, new applications and algorithms Tufts University Computer Science 2

My research l l Compilers are powerful tools Performance improvement l l l Through program transformation Better cooperation with run-time system, OS Error checking l l l Analyze program behavior Try to predict errors – eg, null pointer dereference Try to identify security holes – eg, buffer overrun This problem is wicked hard Tufts University Computer Science 3

Today: Threads l What are they? l Why use ‘em? l Problems – synchronization l Wait, why are we using them? l Off to Dr. Couch’s One. Note presentation… Tufts University Computer Science 4

Why use threads? l Hide latency l Don’t wait for disk access, network transfers, etc l Less overhead than processes l Easier for threads to cooperate than processes l Schedule on multiprocessors l l l True parallelism Near future: all processors will have multiple cores Great, threads are easy, right? l Not so fast… Tufts University Computer Science 5

Synchronization – Motivation l “The too much milk problem” l Thanks to Emery Berger UMass Amherst Example of need to synchronize activities Tufts University Computer Science 6

Example l Consider following routine: int x = 0; void *threaded_routine (void * v) { const int *n = (int *)v; int i; for (i=0; i<10; i++) { int y=x; y++; Increment printf("%d: y=%dn", *n, y); the value of sleep(1); x by one x=y; printf("%d: x=%dn", *n, x); } } Tufts University Computer Science 7

Multithreaded l Run three instances l Should produce “ 30” – three threads increment the value 10 times l How can we fix this? Tufts University Computer Science 8

Solving the Too Much Milk Problem l Correctness properties l l l Only one person buys milk l Safety: “nothing bad happens” Someone buys milk if you need to l Progress: “something good eventually happens” Add some synchronization protocol: l l l “Leave a note” (lock) “Remove a note” (unlock) “Don’t buy milk if there’s a note” (wait) Tufts University Computer Science 9

Too Much Milk: Solution 1 thread A if (no milk && no note) leave note buy milk remove note l thread B if (no milk && no note) leave note buy milk remove note too Does this work? much milk Tufts University Computer Science 10

Too Much Milk: Solution 2 Idea: use labeled notes thread A thread B leave note A if (no note B) if (no milk) buy milk remove note A leave note B if (no note A) if (no milk) buy milk remove note B oops – no milk Tufts University Computer Science 11

Too Much Milk: Solution 3 Idea: wait for the right note thread A thread B leave note A while (note B) do nothing if (no milk) buy milk remove note A leave note B if (no note A) if (no milk) buy milk remove note B l Must try all possibilities to verify Tufts University Computer Science 12

Too Much Milk: Solution 3 Possibility 1: A first, then B thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A l thread B leave note B if (no note A) if (no milk) buy milk remove note B OK Tufts University Computer Science 13

Too Much Milk: Solution 3 Possibility 2: B first, then A thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A l thread B leave note B if (no note A) if (no milk) buy milk remove note B OK Tufts University Computer Science 14

Too Much Milk: Solution 3 Possibility 3: Interleaved – A waits & buys thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A l thread B leave note B if (no note A) if (no milk) buy milk remove note B OK Tufts University Computer Science 15

Too Much Milk: Solution 3 Possibility 4: Interleaved – A waits, B buys thread A leave note A while (note B) do nothing if (no milk) buy milk remove note A l thread B leave note B if (no note A) if (no milk) buy milk remove note B OK Tufts University Computer Science 16

Too Much Milk: Solution 3: “Thread A waits for B, otherwise buys” l Correct – preserves desired properties l l l Safety: we only buy one milk Progress: we always buy milk But… Tufts University Computer Science 17

Problems with this Solution l Complicated l l Asymmetrical l Threads A & B are different Adding more threads = different code for each thread Poor utilization l l Difficult to convince ourselves that it works Busy waiting – consumes CPU resources, no useful work Possibly non-portable l Relies on atomicity of loads & stores Tufts University Computer Science 18

Synchronization Terminology Mutual exclusion (“mutex”) – prevents multiple threads from entering Critical section – code only one thread can execute at a time Race condition – outcome of some code is non-deterministic Lock – mechanism for mutual exclusion Atomic or atomicity – either all completes, or none completes Tufts University Computer Science 19

Locks l Provide mutual exclusion to shared data via two atomic routines l l l Lock: : Acquire – wait for lock, then take it Lock: : Release – unlock, wake up waiters Rules: l l l Acquire lock before accessing shared data Release lock afterwards Lock – initially released Tufts University Computer Science 20

Too Much Milk: Locks thread A thread B Lock. acquire() if (no milk) buy milk Lock. release() Tufts University Computer Science 21

With locks… int x=0; void *threaded_routine (void * v) { const int *n = (int *)v; int i; for (i=0; i<10; i++) { pthread_mutex_lock(&locker); int y=x; y++; printf("%d: y=%dn", *n, y); sleep(1); x=y; printf("%d: x=%dn", *n, x); pthread_mutex_unlock(&locker); } } Tufts University Computer Science 22

Locks l Now run three threads… l What have we accomplished? Made the update of x atomic l Clean, symmetric - but how do we implement it? Tufts University Computer Science 23

Implementing Locks l Requires hardware support (in general) l Can build on atomic operations: l l Load/Store Disable interrupts l l Uniprocessors only Test & Set, Compare & Swap Tufts University Computer Science 24

Race conditions l In practice: These are the most difficult bugs you will ever see l Often occur intermittently l Debugging changes the timing, hides the bug l What to do? l Two neat-o approaches l l Run-time race detection Compile-time race detection Tufts University Computer Science 25

Summary l l l 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 l l Loads & stores: tricky, error-prone Solution: high-level primitives (e. g. , locks) Tufts University Computer Science 26