Fall 2009 Midterm

1. Fall 2009 Midterm CPS 110

2. Scores

3. 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

4. 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?

5. 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

6. 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(); }

7. 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

8. 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(); }

9. 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.

10. Early Winter Borrow (stuff_needed) { lock(); while (stuff_needed ! here) stuff.wait(); take(stuff_needed); unlock(); } Return (gear) { lock(); putback(gear); stuff.broadcast(); unlock(); }