CS444/CS544 Operating Systems Synchronization 2/21/2007 Prof. Searleman

CS444/CS544 Spring 2007 Synchronization w/ semaphores/locks uses problems Deadlock Monitors Reading assignment: Chapter 6 HW#5HW#5 posted: due Monday, 2/26/07

Recap: Uses of Semaphores Mutual exclusion Access to shared resource (critical section) Binary semaphore, initalized to 1 “hold” Managing N copies of a resource Counting semaphore, initialized to N “enter” Anything else? Another type of synchronization is to express ordering/scheduling constraints “Don’t allow x to proceed until after y”

Semaphores for expressing ordering Initialize semaphore value to 0 semaphore synch = 0; Code: P i P j   Await(synch); signal(synch);B Execute B in P j only after A executed in P i regardless of when P i & P j run Note: If signal executes first, wait will find it is an signaled state (history!)

Consider the following code: /* N processes, P 1 … P N */ semaphore mutex = 1; P i : signal(mutex); c.s. wait(mutex); What happens? Answer: It depends, but no guarantee of mutual exclusion

How about this? semaphore S1 = 1; /* protects object O1 */ semaphore S2 = 1; /* protects object O2 */ P 0 : wait(S1); P 1 : wait(S2); wait(S2); wait(S1); /* use O1 & O2 */ /* use O1 & O2 */ signal(S1); signal(S2); signal(S2); signal(S1); What happens? Answer: It depends, but possible deadlock

Deadlock Deadlock exists in a set of processes/threads when all processes/threads in the set are waiting for an event that can only be caused by another process in the set (which is also waiting!). cf. Chapter 7

Preview: Conditions for Deadlock Deadlock can exist if and only if the following four conditions are met: 1. Mutual Exclusion – some resource must be held exclusively 2. Hold and Wait – some process must be holding at least one resource and waiting for another 3. No preemption – resources cannot be preempted 4. Circular wait – there must exist a set of processes (p1,p2, …pn) such that p1 is waiting for p2, p2 is waiting for p3, … pn is waiting for p1

Preview: Handling Deadlock There are a number of ways to handle deadlock. One possibility: Deadlock Prevention that is, guarantee that deadlock cannot occur no matter what How? guarantee that at least one of the four necessary & sufficient conditions for deadlock cannot occur: (1) Mutual Exclusion (2) Hold and Wait (3) No Preemption (4) Circular Wait can’t do much about this we’ll look at these 2 for now (more on this topic later)

Preventing Hold and Wait Do not allow processes to hold a resource when requesting others No partial allocation Window’s WaitForMultipleObjects Make processes ask for all resources they need at the beginning Disadvantage: May not need all resources the whole time Can release them early but must hold until used Make processes release any held resources before requesting more Hard to program!

Preventing Circular wait Impose an ordering on the possible resources and require that processes request them in a specific order Number the resources Always request them in some order, say increasing order Why does this work? How does this apply to the locking lab? (see example done in class)

Recap: Problems with Locks and Semaphores There is no syntactic connection between the semaphore (or lock or event) and the shared data/resources it is protecting Thus the “meaning” of the semaphore is defined by the programmer’s use of it Poor software design  Semaphores basically global variables accessed by all threads Easy for programmers to make mistakes Also no separation between use for mutual exclusion and use for resource management and use for expressing ordering/scheduling constraints

Programming Language Support Add programming language support for synchronization Declare a section of code to require mutually exclusive access (like Java’s synchronized) Associate the shared data itself with the locking automatically Monitor = programming language support to enforce synchronization Mutual exclusion code added by the compiler!

Monitors A monitor is a software module that encapsulates: Shared data structures Procedures that operated on them Synchronization required of processes that invoke these procedures Like a public/private data interface prevents access to private data members; Monitors prevent unsynchronized access to shared data structures

Example: bankAccount Monitor bankAccount{ int balance; int readBalance( ){return balance}; void upateBalance(int newBalance){ balance = newBalance; } int withdraw (int amount) { balance = balance – amount; return balance; } int deposit (int amount){ balance = balance + amount; return balance; } Locking added by the compiler!

Monitor S balance readBalance updateBalance withdraw deposit Shared data Procedures Waiting queue One thread In Monitor

Waiting Inside a Monitor What if you need to wait for an event within one of the procedures of a monitor? Monitors as we have seen to this point enforce mutual exclusion – what about the Introduce another synchronization object, the condition variable Within the monitor declare a condition variable: condition x;

Wait and signal Condition variables, like semaphores, have the two operations have the two operations, wait and signal. The operation x.wait() means that the process invoking this operation is suspended until another process invokes x.signal(); The operation wait allows another process to enter the monitor (or no one could ever call signal!) The x.signal operation resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect

Monitor With Condition Variables S balance readBalance updateBalance withdraw deposit Waiting queue One thread Running in Monitor Condition Variables and their associated wait queues

Semaphores vs Condition Variables I’d like to be able to say that condition variables are just like semaphores but … With condition variables, if no process is suspended then the signal operation has no effect With semaphores, signal increments the value regardless of whether any process is waiting Semaphores have “history” (they remember signals) while condition variables have no history

Condition Variable Alone? Could you use a condition variable concept outside of monitors? Yes, basically a semaphore without history Couldn’t do locking with it because no mutual exclusion on its own Couldn’t do resource management (counting semaphore) because no value/history Can use it for ordering/scheduling constraints (more on this later)