1. CS444/CS544 Operating Systems Deadlock 3/7/2007 Prof. Searleman jets@clarkson.edu

2. Outline Summary: Synchronization Handling Deadlock NOTE: Next topic: Memory Management, Chapters 8–9 Makeup class on Friday 3/09/07: section §10: lab@1:00 in ITL; lecture@2:00 in SC356 section §20: lecture@1:00 in SC342; lab@2:00 in ITL Exam#2 – Tues. 3/13, 7:00 pm, SC160 Exam#2

3. void startRead(){ if ( busy || (waitingWriters > 0) ) { waitingReader++; OKtoRead.wait(); waitingReaders--; } readercount = readercount + 1; OKtoRead.signal(); } void endRead(){ readercount = readercount - 1; if (readercount == 0) OKtoWrite.signal(); } can a newly arriving reader enter the queue for OKtoRead? could this starve a waiting writer? Recap: Reader/Writer Monitor

4. // Monitor procedures for writers: void startWrite(){ if ( (readercount != 0) || busy ) { waitingWriters++; OKtoWrite.wait(); waitingWriters--; } busy = true; } void endWrite(){ busy = false; if (waitingReaders > 0) OKtoRead.signal(); else OKtoWrite.signal(); }

5. Remember Game is obtaining highest possible degree of concurrency and greatest ease of programming Tension Simple high granularity locks easy to program Simple high granularity locks often means low concurrency Getting more concurrency means Finer granularity locks, more locks More complicated rules for concurrent access

6. Pseudo-Monitors Monitor = a lock (implied/added by compiler) for mutual exclusion PLUS zero or more condition variables to express ordering constraints What if we wanted to have monitor without programming language support? Declare locks and then associate condition variables with a lock If wait on the condition variable, then release the lock Java – “synchronized” methods

7. Example: Pseudo-monitors pthread_mutex_t monitorLock; pthread_cond_t conditionVar; void pseudoMonitorProc(void) { pthread_mutex_lock(&mutexLock); ….. pthread_cond_wait(&conditionVar, &monitorLock); …. pthread_mutex_unlock(&mutexLock); }

8. Synchronization Mechanisms Hardware Solutions disable/enable interrupts uninterruptible machine instruction (e.g. test-and-set, swap) Software Solutions Peterson’s solution and variations semaphores: counting & binary semaphores spinlock semaphores monitors condition variables Thread packages: mutex (lock), condition variables, reader- writer locks Events, Message Passing, Timers, Regions, and others… (busy waiting) (blocking) (blocks other threads from running) (blocking)

9. Software Synchronization Primitives Summary Locks Simple semantics, often close to HW primitives Can be inefficient if implemented as a spin lock Semaphores Internal queue – more efficient if integrated with scheduler Monitors Language constructs that automate the locking Easy to program with where supported and where model fits the task Once add in condition variables much of complexity is back Events/Messages Simple model of synchronization via data sent over a channel

10. ValueQueue“acquire” op “release” op “broadcast” or “release all” op Lock 0/1? Lock Block till value = 0; set value = 1 Unlock value = 0No Semaphore intY Wait, down, P value— If value < 0 add self to queue Signal, up, V value++ If value <= 0 wake up one No? while (getValue()<0) { signal() } Condition variable N/AY Wait Put self on queue Signal If process on queue, wake up exactly one Easy to support a signal all Monitor N/AY Call proc in monitorReturn from proc in monitor No

11. Semaphores vs Monitors If have one you can implement the other…

12. Converting a monitor solution to a semaphore solution Basic concept: Each condition c; simulated with semaphore cSem = 0; For mutual exclusion, introduce a new semaphore: semaphore mutex = 1; A wait on a condition variable c: c.wait() becomes: signal(mutex); // release exclusion wait(cSem); // block wait(mutex); // regain exclusion before accessing // shared variables What about a signal on a condition variable?

13. Implementing Monitors with Semaphores semaphore_t mutex, next; int nextCount = 1; Initialization code: mutex.value = 1; next.value = 0; For each procedure P in Monitor, implement P as Wait (mutex); unsynchronizedBodyOfP(); if (nextCount >0){ signal(next); }else { signal(mutex); } conditionVariable_t { int count; semaphore_t sem; } condWait (conditionVariable_t *x) { //one more waiting on this cond x->count = x_count++; if (nextCount > 0){ signal(next); //wake up someone } else { signal (mutex); } wait(x->sem); x->count = x->count--; } condSignal(conditionVariable_t *x){ //if no one waiting do nothing! if (x->count > 0){ next_count = nextCount++; signal(x->sem); wait (next); nextCount--; } }

14. Implementing Semaphores With Monitors Monitor semaphore { int value; condition waitQueue; void wait(){ value--; while (value < 0){ //Notice Mesa semantics condWait(&waitQueue); } void signal(){ value++; condSignal(&waitQueue) ; } } //end monitor semaphore void setValue(int value){ value = newValue; } int getValue(){ return value; }

15. Need for Synchronization Have a number of cooperating, sequential processes/threads running asynchronously. When must they synchronize? When timing or ordering of execution is required e.g. one process/thread must wait for another When sharing a resource Each process/thread does the following request/acquire the resource; use the resource; release the resource; resources: shared variables/files, buffers, devices (such as printers), databases, etc.

16. Criteria for a “good” solution Mutual exclusion is preserved The progress requirement is satisfied The bounded-waiting requirement is met. In other words, you want the solution to be correct (under any circumstances) without any assumptions about relative running times (no race conditions possible) fair not subject to starvation (indefinite postponement) or deadlock

17. Synchronization Mechanisms It is common for Operating Systems to have a variety of synchronization mechanisms. Solaris adaptive mutexes, condition variables, semaphores, reader- writer locks, turnstiles Windows XP dispatcher objects: mutexes, semaphores, events, timers Linux spinlocks, semaphores, reader-writer locks, Pthread API (mutex locks, condition variables, read-write locks) Why??

18. Summary: Synchronization Synchronization primitives all boil down to controlling access to a shared state (or resource) with a small amount of additional shared state All need to be built on top of HW support Once have one kind, can implement the others Which one you use is a matter of matching the primitive to the problem short-term locking: spinlocks, mutexes longer-term locking: counting semaphores, condition variables read-only access with occasional writes: reader-writer locks

19. Deadlock (aka “Deadly Embrace”) Compliments of Oleg Dulin, CS major, Clarkson alumni

20. Methods for Handling Deadlock Allow deadlock to occur, but… Ignore it (ostrich algorithm) Detection and recovery Ensure that deadlock never occurs, by… Prevention (negate at least 1 of the 4 necessary conditions for deadlock to occur) Dynamic avoidance (be careful) What are the consequences? May be expensive Constrains how requests for resources can be made Processes must give maximum requests in advance