CS 444CS 544 Operating Systems Synchronization 2212007 Prof

  • Slides: 21
Download presentation
CS 444/CS 544 Operating Systems Synchronization 2/21/2007 Prof. Searleman jets@clarkson. edu

CS 444/CS 544 Operating Systems Synchronization 2/21/2007 Prof. Searleman jets@clarkson. edu

CS 444/CS 544 l Synchronization w/ semaphores/locks l l Spring 2007 uses problems Deadlock

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

Recap: Uses of Semaphores l Mutual exclusion l l Managing N copies of a

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

Semaphores for expressing ordering l Initialize semaphore value to 0 l l semaphore synch

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

Consider the following code: /* N processes, P 1 … PN */ semaphore mutex

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

How about this? semaphore S 1 = 1; /* protects object O 1 */

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

Deadlock l Deadlock exists in a set of processes/threads when all processes/threads in the

Deadlock l 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!). l cf. Chapter 7

Preview: Conditions for Deadlock can exist if and only if the following four conditions

Preview: Conditions for Deadlock can exist if and only if the following four conditions are met: 1. 2. 3. 4. 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 (p 1, p 2, …pn) such that p 1 is waiting for p 2, p 2 is waiting for p 3, … pn is waiting for p 1

Preview: Handling Deadlock There a number of ways to handle deadlock. One possibility: Deadlock

Preview: Handling Deadlock There a number of ways to handle deadlock. One possibility: Deadlock Prevention l that is, guarantee that deadlock cannot occur no matter what How? l 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 l Do not allow processes to hold a resource when

Preventing Hold and Wait l Do not allow processes to hold a resource when requesting others l l l Make processes ask for all resources they need at the beginning l l l No partial allocation Window’s Wait. For. Multiple. Objects 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 l Hard to program!

Preventing Circular wait l Impose an ordering on the possible resources and require that

Preventing Circular wait l Impose an ordering on the possible resources and require that processes request them in a specific order l l 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 l l There is no syntactic connection between

Recap: Problems with Locks and Semaphores l l There is no syntactic connection between the semaphore (or lock or event) and the shared data/resources it is protecting l Thus the “meaning” of the semaphore is defined by the programmer’s use of it l Poor software design § Semaphores basically global variables accessed by all threads l 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 l Add programming language support for synchronization l l l Declare

Programming Language Support l Add programming language support for synchronization l l l 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 l Mutual exclusion code added by the compiler!

Monitors l A monitor is a software module that encapsulates: l l Shared data

Monitors l A monitor is a software module that encapsulates: l l 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: bank. Account Monitor bank. Account{ int balance; int read. Balance( ){return balance}; void

Example: bank. Account Monitor bank. Account{ int balance; int read. Balance( ){return balance}; void upate. Balance(int new. Balance){ balance = new. Balance; } int withdraw (int amount) { Locking added by the compiler! balance = balance – amount; return balance; } int deposit (int amount){ balance = balance + amount; return balance; } }

Monitor balance One thread In Monitor Waiting queue Shared data read. Balance S update.

Monitor balance One thread In Monitor Waiting queue Shared data read. Balance S update. Balance withdraw deposit Procedures

Waiting Inside a Monitor l l What if you need to wait for an

Waiting Inside a Monitor l l 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 l Condition variables, like semaphores, have the two operations, wait and

Wait and signal l Condition variables, like semaphores, have the two operations, wait and signal. l l l 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 and their associated wait queues One thread Running in Monitor

Monitor With Condition Variables and their associated wait queues One thread Running in Monitor Waiting queue balance read. Balance S update. Balance withdraw deposit

Semaphores vs Condition Variables l l I’d like to be able to say that

Semaphores vs Condition Variables l l 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? l l Could you use a condition variable concept outside of

Condition Variable Alone? l l Could you use a condition variable concept outside of monitors? Yes, basically a semaphore without history l l l 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)