Class Note for CMPSCI 377 at UMass(33)
Class Note for CMPSCI 377 at UMass(33)
Popular in Course
Popular in Department
This 3 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at University of Massachusetts taught by a professor in Fall. Since its upload, it has received 32 views.
Reviews for Class Note for CMPSCI 377 at UMass(33)
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 02/06/15
CMPSCI 377 Operating Systems Spring 2009 Lecture 11 March 3 Lecturer Mark Corner Scribes Bruno Silvaim Partzm 111 Blocking Locks and Multiple CPUS At the end of last class we talked about blocking locks which voluntarily yield and spinlocks which just spin until they acquire the lock At rst it seems like spinlocks are very wasteful and that one should always use blocking locks But this question is a bit more complicated than that In wellwritten code locks are only held around small pieces of code so they should not be held for very long On a multi processor system it often makes sense to use spinlocks since the thread holding the lock will likely release the lock soon and may be running simultaneously on another processor about to release the lock This question is further complicated however by the possibility of pagefaults see virtual memory later in this course Pagefaults or similar hardto predict delays could make even wellwritten multithreaded code hold locks for longer than anticipated A hybrid type of lock called spintherLyield locks will spin for some amount of time and if it still hasn7t acquired the lock yield A spinthenyield lock can be adaptive in the amount of time it spins before yielding 112 Major locking errors When programming with threads there are three very common mistakes that programmers often make 1 locking twice depending on the system and type of lock can cause crashes hangs or do bizarre things 2 locking and not unlocking Le failure to unlock 3 deadlock see next lecture Of these problems locking twice is probably the easiest type of error to detect Here s one example function f C function g lockL lockL g0 access shared data unlockL unlockL So called recursive locks can deal with this situation correctly though normal locks will cause this thread to wait forever when the function g when called from f then calls lockL on a previouslyheld lock Dealing with this can lead to a common code pattern with certain functions designed only to be called with locks held 111 112 Lecture 11 March 3 function f function g function ginternal lockL lockL locks must be held here ginternal ginternal access shared data unlockL unlockL Failure to unlock is slightly more difficult to detect It can occur for example if the programmer forgets to release the lock in one of the possible execution branches of the function function f lock if x0 should also unlock here before returning return do something unlock return One way to deal with this is just to remember to unlock at each possible return Another is to have every return path go through the same section of code and in C goto is sometimes useful for this despite its bad reputation 113 Increasing Concurrency ReadWrite Locks Consider a large webbased database In some sense Google is sort of like this There might be many users who want to read from the database but only a few users who are allowed to write to the database If we use standard locks to control access to the database the application will be much slower than it could be with a more clever type of lock Suppose we have one object that is shared among several threads Suppose also that each thread is either a reader or a writer Readers only read data but never modify it while writers read and modify data If we know which threads are reading and which ones are writing what can we do to increase concurrency First we have to prevent two writers from writing at the same time In addition a reader cannot read while a writer is writing There is no problem however in allowing lots of readers to read at the same time Readwrite locks achieve this and can greatly improve performance for this sort of application 114 Deadlocks At the end of this lecture and into the next lecture we will discuss the last major type of logical error that can occur when programming with threadsi A deadlock occurs when two things threads processes etc wait on each other One example of a deadlock is known as the Dining Philosophers problemi In this abstract problem philoso phers alternate between thinking and eating and the dining table has as many forks as philosophers Each philosopher needs two forks to eat with The problem which can occur is if each philosopher gets one fork Lecture 11 March 3 113 and Will not let go of it Then no philosopher can get two forks7 Which he or she needs in order to eat In this situation7 we have a deadlock and the philosophers Will starve In the next lecture7 we Will nish discussing the deadlock problemi
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'