CSE451 Section 5:Spring 2006

AA: Kurtis Heimerl(kheimerl@cs)AB: YongChul Kwon(yongchul@cs)

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

Why multi-* programming? What can replace ‘*’?

Why do we need them?

What should we sacrifice to implement them?

What are the challenges?

Examples of multi-* programming Can you give examples of concurrent

programs you use and why they are?

Model the real world! Single threaded program

Work alone Deterministic Slow(?) Not fun!

Multi-* program Work together Non-deterministic Fast(?) Fun! :-D

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

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

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?

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’

Deadlock What is it?

Why does it happen?

What are the strategies to resolve it?

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?

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

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

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

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

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.