CS444/CS544 Operating Systems

1. CS444/CS544Operating Systems Synchronization 2/21/2007 Prof. Searleman jets@clarkson.edu

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

3. 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”

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

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

6. How about this? semaphore S1 = 1; /* protects object O1 */ semaphore S2 = 1; /* protects object O2 */ P0: wait(S1); P1: 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

7. 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

8. Preview: Conditions for Deadlock Deadlock can exist if and only if the following four conditions are met: • Mutual Exclusion – some resource must be held exclusively • Hold and Wait – some process must be holding at least one resource and waiting for another • No preemption – resources cannot be preempted • 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

9. can’t do much about this we’ll look at these 2 for now (more on this topic later) 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

10. 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!

11. 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)

12. 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

13. 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!

14. 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

15. 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!

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

17. 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;

18. 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

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

20. 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

21. 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)