COMP 111 Threads and concurrency Sept 28, 2005

Tufts University Computer Science2 Who is this guy? I am not Prof. Couch Obvious? Sam Guyer 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 Science3 My research Compilers are powerful tools Performance improvement Through program transformation Better cooperation with run-time system, OS Error checking 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 Science4 Today: Threads What are they? Why use ‘em? Problems – synchronization Wait, why are we using them? Off to Dr. Couch’s OneNote presentation…

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

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

Tufts University Computer Science7 Example 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++; printf("%d: y=%d\n",*n,y); sleep(1); x=y; printf("%d: x=%d\n",*n,x); } Increment the value of x by one

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

Tufts University Computer Science9 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” Add some synchronization protocol: “Leave a note” (lock) “Remove a note” (unlock) “Don’t buy milk if there’s a note” (wait)

Tufts University Computer Science10 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

Tufts University Computer Science11 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

Tufts University Computer Science12 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

Tufts University Computer Science13 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

Tufts University Computer Science14 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

Tufts University Computer Science15 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

Tufts University Computer Science16 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

Tufts University Computer Science17 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…

Tufts University Computer Science18 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

Tufts University Computer Science19 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 Science20 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

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

Tufts University Computer Science22 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=%d\n",*n,y); sleep(1); x=y; printf("%d: x=%d\n",*n,x); pthread_mutex_unlock(&locker); }

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

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

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

Tufts University Computer Science26 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)