Thread CPS110: cooperation
Landon Cox
January17, 2008
Constraining concurrency
Synchronization
Controlling thread interleavings
Some events are independent
No shared state Relative order of these events don't matter
Other events are dependent
Output of one can be input to another Their order can affect program results
Goals of synchronization
1. All interleavings must give correct result
Correct concurrent program
Works no matter how fast threads run
Important for your projects!
2. Constrain program as little as possible
Constraints slow program down Constraints create complexity
"Too much milk" principals
"Too much milk" rules
The fridge must be stocked with milk
Milk expires quickly, so never > 1 milk
Landon and Melissa
Can come home at any time If either sees an empty fridge, must buy milk Code (no synchronization)
if (noMilk){ buy milk; }
Unsynchronized code will break
Time 3:00 Look in fridge (no milk) 3:05 3:10 3:15 3:20 3:25 3:30 3:35 Arrive home, stock fridge Buy milk Arrive home, stock fridge Too much milk! Buy milk Go to grocery store Go to grocery store Look in fridge (no milk)
What broke?
Code worked sometimes, but not always
Code contained a race condition Processor speed caused incorrect result
First type of synchronization
Mutual exclusion Critical sections
Synchronization concepts
Mutual exclusion
Ensure 1 thread doing something at a time E.g. 1 person shops at a time Code blocks are atomic w/re to each other Threads can't run code blocks at same time
Synchronization concepts
Critical section
Code block that must run atomically
"with respect to some other pieces of code"
If A and B are critical w/re to each other
Threads mustn't interleave events in A and B A and B mutually exclude each other
Often conflicting code is same block
But executed by different threads Reads/writes shared data (e.g. screen, fridge)
Back to "Too much milk"
What is the critical section?
if (noMilk){ buy milk; }
Landon and Melissa's critical sections
Must be atomic w/re to each other
"Too much milk" solution 1
Assume only atomic load/store
Build larger atomic section from load/store
Idea:
1.Leave notes to say you're taking care of it 2.Don't check milk if there is a note
Solution 1 code
if (noMilk) { if (noNote){ leave note; buy milk; remove note; } }
Atomic operations
Atomic load: check note Atomic store: leave note
Does it work?
if (noMilk) { if (noMilk) { 1 if (noNote){ 2 if (noNote){ leave note; leave note; 3 buy milk; 4 buy milk; remove note; remove note; } } } } Is this better than no synchronization at all? What if "if" sections are switched?
What broke?
Melissa's events can happen
After Landon checks for a note Before Landon leaves a note
if (noMilk) { if (noNote){ leave note; buy milk; remove note; } }
Next solution
Idea:
Change the order of "leave note", "check note" Requires labeled notes (else you'll see your note)
Does it work?
leave noteLandon if (no noteMelissa){ if (noMilk){ buy milk; } } remove noteLandon leave noteMelissa if (no noteLandon){ if (noMilk){ buy milk; } } remove noteMelissa
Nope. (Illustration of "starvation.")
What about now?
while (noMilk){ leave noteLandon if(no noteMelissa){ if(noMilk){ buy milk; } } remove noteLandon } while (noMilk){ leave noteMelissa if(no noteLandon){ if(noMilk){ buy milk; } } remove noteMelissa }
Nope. (Same starvation problem as before)
Next solution
We're getting closer Problem
Who buys milk if both leave notes?
Solution
Let Landon hang around to make sure job is done
Does it work?
leave noteLandon while (noteMelissa){ do nothing } if (noMilk){ buy milk; } remove noteLandon leave noteMelissa if (no noteLandon){ if (noMilk){ buy milk; } } remove noteMelissa
Yes! It does work! Can you show it?
Downside of solution
Complexity
Hard to convince yourself it works
Asymmetric
Landon and Melissa run different code
Not clear if this scales to > 2 people Landon consumes CPU while waiting
Busy-waiting
Note: only needed atomic load/store
Raising the level of abstraction
Mutual exclusion with atomic load/store
Painful to program Wastes resources
Need more HW support Will be covered later
OS can provide higher level abstractions
Course administration
Project 0
Due on Tuesday Do not use you late days on P0
(only worth 2% of your grade)
Save your late days for bigger projects 3 groups have submitted
Questions about Project 0?
Course administration
void main () { // create a new list Dlist<foo> *list = new Dlist<foo> (); // insert a new object list->insertFront (new foo ()); How much memory // remove and delete the object should be allocated here? delete list->removeFront (); // insert another object How much memorylist->insertFront (new foo ()); should be allocated // delete the list here? delete list; }
Course administration
Project 1 (two parts)
1. Write a small concurrent program 2. Implement a thread library (single CPU)
Create new threads Switch between threads Manage interactions btw cooperating threads
Out on Tuesday, should be able to start
E.g. disk scheduler input routine
Course administration
Groups
Everyone have should a group Everyone should have a CS account
Discussion section
Tuesdays and Wednesdays
Any other questions?
Too much milk solution
leave noteLandon while (noteMelissa){ do nothing } if (noMilk){ buy milk; } remove noteLandon leave noteMelissa if (no noteLandon){ if (noMilk){ buy milk; } } remove noteMelissa
Downside of solution
Complexity
Hard to convince yourself it works
Asymmetric
Landon and Melissa run different code
Not clear if this scales to > 2 people Landon consumes CPU while waiting
Busy-waiting
Note: only needed atomic load/store
Raising the level of abstraction
Locks
Also called mutexes Provide mutual exclusion Prevent threads from entering a critical section
Lock operations
Lock (aka Lock::acquire) f Unlock (aka Lock::release)
Lock operations
Lock: wait until lock is free, then acquire it
Must be atomic with respect to other threads calling this code This is a busy-waiting implementation
We'll improve on this in a few lectures
do { if (lock is free) { acquire lock break } } while (1)
Unlock: atomic release lock
Too much milk, solution 2
if (noMilk) { if (noNote){ leave note; buy milk; remove note; } }
Block is not atomic. Must atomically check if lock is free grab it
Why doesn't the note work as a lock?
Elements of locking
1. The lock is initially free 2. Threads acquire lock before an action 3. Threads release lock when action completes 4. Lock() must wait if someone else has lock
Key idea
All synchronization involves waiting
Threads are either running or
Too much milk with locks?
lock () if (noMilk) { buy milk } unlock ()
lock () if (noMilk) { buy milk } unlock ()
Problem?
Waiting for lock while other buys milk
Too much milk "w/o waiting"?
lock () if (noNote && noMilk){ leave note "at store" Not holding unlock () buy milk lock lock () remove note unlock () } else { unlock () } lock () if (noNote && noMilk){ leave note "at store" unlock () buy milk lock () remove note unlock () } else { unlock () }
Only hold lock while handling shared resource.
What about this?
lock () if (noMilk && noNote){ leave note "at store" unlock () buy milk stock fridge remove note } else { unlock () }
2 4
1 3
lock () if (noMilk && noNote){ leave note "at store" unlock () buy milk stock fridge remove note } else { unlock () }
Example: thread-safe queue
enqueue () { lock (qLock) // ptr is private // head is shared node *ptr; // find queue tail for (ptr=head; ptr->next!=NULL; ptr=ptr->next){} ptr->next=new_element; new_element->next=0; unlock(qLock); } dequeue () { lock (qLock); element=NULL; // if queue non-empty if (head!=0) { // remove head element=head->next; head->next=NULL; } unlock (qLock); return element; }
What can go wrong?
Thread-safe queue
Can enqueue unlock anywhere?
No
enqueue () { lock (qLock) node *ptr; for (ptr=head; ptr->next!=NULL; ptr=ptr->next){} ptr->next=new_element; unlock(qLock); // safe? new_element->next=0; }
Must leave shared data
In a consistent/sane state
D...