1. CSE451 Section 5: Spring 2006 AA: Kurtis Heimerl(kheimerl@cs) AB: YongChul Kwon(yongchul@cs)

2. Questions?  Part 1, 2, 3?  Midterm?  Private?

3. Why multi-* programming?  What can replace ‘*’?  Why do we need them?  What should we sacrifice to implement them?  What are the challenges?

4. Examples of multi-* programming  Can you give examples of concurrent programs you use and why they are?

5. Model the real world!  Single threaded program Work alone Deterministic Slow(?) Not fun!  Multi-* program Work together Non-deterministic Fast(?) Fun! :-D

6. Using a vending machine  Alone Insert coins Select item Pick up  More people Insert coins Select… A person behind you push the button and ran away ?!?!  What do we need? From vendtronics.com

7. Model the vending machine Vendingmachine vm; Item i; Money m; vm.lock(); vm.insertCoin($.5); vm.insertBill($1); i = vm.selectRandom(); m = vm.giveMeTheChange(); vm.unlock();

8. Intersection  Alone GO! GO! GO!  Together The traffic light changed to green Stepped gas pedal A car driving 80mph collided left side of your car There was no side-air bag RIP...  What do we need?

9. Model the intersection  Assumption Suppose at most 10 cars in each direction can proceed at one signal The roads are toward exact N, E, W, S direction  Given classes Intersection  enum { NS, EW } signalDir: ‘++’ would return next signal Road  It is a simple queue Car  You can obtain direction using ‘toward’

10. Deadlock  What is it?  Why does it happen?  What are the strategies to resolve it?

11. Starvation  Pathfinder @ 1997 Mission on Mars VxWorks: realtime OS supports preemptive priority thread scheduling Information bus  data path between components  Synchronized by using mutex Priority  Bus Management > COMMunication > Meteorological Data Gathering  BM task: Use information bus. Run frequently  COMM task: Long running time  MDG: Run not very often. Use information bus Result  System reset  Data loss  Why? How can we solve this?

12. Deadlock prevention  Linux kernel documentation contains a lot of rules about locking find. –name “*[lL]ock*” grep deadlock *  Why? Because there are 5000 locks in 2003  Lots of them specifying explicit rules about acquiring locks The rules are: 1. To scan the vmlist (look but don't touch) you must hold the mmap_sem with read bias, i.e. down_read(&mm- >mmap_sem) 2. To modify the vmlist you need to hold the mmap_sem with read&write bias, i.e. down_write(&mm->mmap_sem) *AND* you need to take the page_table_lock. 3. The swapper takes _just_ the page_table_lock, this is done because the mmap_sem can be an extremely long lived lock and the swapper just cannot sleep on that. 4. The exception to this rule is expand_stack, which just takes the read lock and the page_table_lock, this is ok because it doesn't really modify fields anybody relies on. 5. You must be able to guarantee that while holding page_table_lock or page_table_lock of mm A, you will not try to get either lock for mm B. -- From vm/locking 1. The symbolic link name, if any (/var/lock/LCK..modem) 2. The "tty" name (/var/lock/LCK..ttyS2) 3. The alternate device name (/var/lock/LCK..cua2) -- From devices.txt  Let’s have a look at file system

13. Lock the file system  Characteristics of file system Nearly all programs use file system Believed as a permanent & consistent data storage Unfortunately, we have many programs run simultaneously  Linux There are more than 20 VFS related locking rules Refer Documentation/filesystems

14. Locking related to directory operation  From filesystems/directory-locking  Read access & create object Lock the target directory  Object removal & rename & link creation Lock the parent Lock the target object  Cross directory rename Lock the file system Lock parents in ancestors first order Lock target if exists  Cross directory rename looks complex. Is it really deadlock free? The documentation contains proof

15. Sketch of proof  Followings are true (1) The locked parent A remains as the parent of an object B until we acquire the lock of B (2) Once a cross directory renaming holds the lock on filesystem, the order of locking path won’t change until it acquires all locks (3) Any operation holds a lock on non-directory object and that lock is acquired after all other locks

16. Sketch of proof – cont’d  Suppose there are processes contending locks filesystem lock is not the one contending – by (1) Non-directory object lock is not contenting – by (3) Except cross-directory rename, all other contending processes are blocked due to (1) If there is another lock blocking the cross directory renaming process, one of its descendents is locked by the other operation. Due to (2) and by the locking rule, it is impossible.