CS162 Operating Systems and Systems Programming Lecture 7 Mutual Exclusion Semaphores Monitors and Condition Variables September 22 2008 Prof John Kubiatowicz http inst eecs berkeley edu cs162 Review Synchronization problem with Threads One thread per transaction each running Deposit acctId amount acct GetAccount actId May use disk I O acct balance amount StoreAccount acct Involves disk I O Unfortunately shared state can get corrupted Thread 1 Thread 2 load r1 acct balance load r1 acct balance add r1 amount2 store r1 acct balance add r1 amount1 store r1 acct balance Atomic Operation an operation that always runs to completion or not at all It is indivisible it cannot be stopped in the middle and state cannot be modified by someone else in the middle 9 22 08 Kubiatowicz CS162 UCB Fall 2008 Lec 7 2 Review Too Much Milk Solution 3 Here is a possible two note solution Thread A Thread B leave note A while note B X do nothing buy milk if noMilk buy milk remove note B remove note A leave note B if noNote A Y if noMilk Does this work Yes Both can guarantee that It is safe to buy or Other will buy ok to quit At X if no note B safe for A to buy otherwise wait to find out what will happen At Y if no note A safe for B to buy Otherwise A is either buying or waiting for B to quit 9 22 08 Kubiatowicz CS162 UCB Fall 2008 Lec 7 3 Review Solution 3 discussion Our solution protects a single Critical Section piece of code for each thread if noMilk buy milk Solution 3 works but it s really unsatisfactory Really complex even for this simple an example Hard to convince yourself that this really works A s code is different from B s what if lots of threads Code would have to be slightly different for each thread While A is waiting it is consuming CPU time This is called busy waiting There s a better way Have hardware provide better higher level primitives than atomic load and store Build even higher level programming abstractions 9 22 08 Kubiatowicz CS162 UCB Fall 2008 Lec 7 4 on this new hardware support Goals for Today Hardware Support for Synchronization Higher level Synchronization Abstractions Semaphores monitors and condition variables Programming paradigms for concurrent programs Note Some slides and or pictures in the following are adapted from slides 2005 Silberschatz Galvin and 9 22 08 Kubiatowicz CS162 UCB Fall 2008 Lec 7 5 Gagne Many slides Gagne generated from my lecture notes High Level Picture The abstraction of threads is good Maintains sequential execution model Allows simple parallelism to overlap I O and computation Unfortunately still too complicated to access state shared between threads Consider too much milk example Implementing a concurrent program with only loads and stores would be tricky and error prone Today we ll implement higher level operations on top of atomic operations provided by hardware Develop a synchronization toolbox Explore some common programming paradigms 9 22 08 Kubiatowicz CS162 UCB Fall 2008 Lec 7 6 Too Much Milk Solution 4 Suppose we have some sort of implementation of a lock more in a moment Lock Acquire wait until lock is free then grab Lock Release Unlock waking up anyone waiting These must be atomic operations if two threads are waiting for the lock and both see it s free only one succeeds to grab the lock Then our milk problem is easy milklock Acquire if nomilk buy milk milklock Release Once again section of code between Acquire and Release called a Critical Section Of course you can make this even simpler suppose you are out of ice cream instead of milk Skip the test since you always need more ice cream 9 22 08 Kubiatowicz CS162 UCB Fall 2008 Lec 7 7 How to implement Locks Lock prevents someone from doing something Lock before entering critical section and before accessing shared data Unlock when leaving after accessing shared data Wait if locked Important idea all synchronization involves waiting Should sleep if waiting for a long time Atomic Load Store get solution like Milk 3 Looked at this last lecture Pretty complex and error prone Hardware Lock instruction Is this a good idea What about putting a task to sleep How do you handle the interface between the hardware and scheduler Complexity 9 22 08 Done in the Intel 432 Each feature makes hardware more complex and slow Kubiatowicz CS162 UCB Fall 2008 Lec 7 8 Na ve use of Interrupt Enable Disable How can we build multi instruction atomic operations Recall dispatcher gets control in two ways Internal Thread does something to relinquish the CPU External Interrupts cause dispatcher to take CPU On a uniprocessor can avoid context switching by Avoiding internal events although virtual memory tricky Preventing external events by disabling interrupts Consequently na ve Implementation of locks LockAcquire disable Ints LockRelease enable Ints Problems with this approach Can t let user do this Consider following LockAcquire While TRUE Real Time system no guarantees on timing Critical Sections might be arbitrarily long What happens with I O or other important events 9 22 08 Reactor about to meltdown Kubiatowicz CS162 UCBHelp Fall 2008 Lec 7 9 Better Implementation of Locks by Disabling Interrupts Key idea maintain a lock variable and impose mutual exclusion only during operations on that variable int value FREE Acquire Release disable interrupts disable interrupts if value BUSY if anyone on wait queue take thread off wait queue put thread on wait queue Place on ready queue Go to sleep else Enable interrupts value FREE else value BUSY enable interrupts enable interrupts 9 22 08 Kubiatowicz CS162 UCB Fall 2008 Lec 7 10 New Lock Implementation Discussion Why do we need to disable interrupts at all Avoid interruption between checking and setting lock value Otherwise two threads could think that they both have lock Acquire disable interrupts if value BUSY put thread on wait queue Go to sleep Enable interrupts else value BUSY enable interrupts Critical Section Note unlike previous solution the critical section inside Acquire is very short User of lock can take as long as they like in their own critical section doesn t impact global machine behavior 9 22 08 Kubiatowicz CS162 UCB Fall 2008 Lec 7 11 Critical interrupts taken in time Interrupt re enable in going to sleep What about re enabling ints when going to sleep Enable Position Enable Position Enable Position Acquire disable interrupts if value BUSY put thread on wait queue Go to sleep else value BUSY enable interrupts Before Putting thread on the wait queue
View Full Document
Unlocking...