Transcript midterm.ppt

Fall 2009 Midterm
CPS 110
Scores
Threads T/F
• Two free “wrong” answers
• “…the code that your team wrote…”
• #1: like a kernel, all code runs in a thread context
• Except “interrupts”
• #3: no stack guard can be guaranteed
• #6: disabling interrupts on underlying hardware is a
privileged operation
• #10: mesa vs. hoare
More Threads
• Part 1
• Global variable (or one per core)
• Block or yieldfrom
• Part 2
• Unlock, signal, broadcast, yieldto
• Exit (both sides)
• Pick it up from a queue somewhere
• How to delete thread after exit?
Sweet Tooth with Mutex/CV
• Old problem
• Simple 1-1 producer/consumer
• The bar is the “bounded buffer”
• Three different “products” targeted to specific
consumers
• Both producer and consumer must wait
• Producer must signal the “right” consumer
• (or broadcast and let them sort it out)
• Consumer must signal producer
Sweet Tooth
Donate (int cents_donated) {
// flush student is producer
lock();
while (money_on_table != 0)
producer.wait();
money_on_table += cents_donated;
philosophers.broadcast();
unlock();
}
Consume (int cents_needed) {
// lush philosophers are consumers
lock();
while (money_on_table != cents_needed)
philosophers.wait();
take_the_money();
producer.signal();
unlock();
}
Sweet Tooth with Sem
• No Locks Needed!
• Simple 1-1 producer/consumer
• The bar is the “bounded buffer”
• Three “products” targeted to specific consumers
• Both producer and consumer must P
• Producer must V the “right” consumer
• Trick: use a sem per consumer
• Chain-gang approach is ugly but probably OK
• Consumer must V producer
Sweet Tooth
producer.Init(1);
Donate (int cents_donated) {
// flush student is producer
producer.P();
sem[cents_donated].V();
}
Consume (int cents_needed) {
// lush philosophers are consumers
sem[cents_needed].P();
producer.V();
}
Early Winter
• Easy: standard resource allocator.
• Lots to worry about before doing the obvious.
• Borrow() may wait, Return() never waits.
• One fat lock, one fat condition variable.
• Grab everything at once iff you can: no hold-and-wait.
• Hold-and-wait is not REALLY incorrect…
• No borrower should be stuck while resources are ready
• But then starvation/livelock COULD occur
• No solution is perfectly fair with a nondeterministic
scheduler.
• Broadcast() and let the borrowers scramble.
Early Winter
Borrow (stuff_needed) {
lock();
while (stuff_needed ! here)
stuff.wait();
take(stuff_needed);
unlock();
}
Return (gear) {
lock();
putback(gear);
stuff.broadcast();
unlock();
}