CS444/CS544Operating Systems

Synchronization

2/21/2007

Prof. Searleman

jets@clarkson.edu

CS444/CS544 Spring 2007 Synchronization w/ semaphores/locks

uses problems

Deadlock Monitors

Reading assignment: Chapter 6

HW#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: Pi Pj

A wait(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!)

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

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

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 whatHow? 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: bankAccountMonitor 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 addedby the compiler!

Monitor

S

balance

readBalance

updateBalance

withdraw

deposit

Shared data

ProceduresWaiting queue

One threadIn 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 threadRunning in Monitor

Condition Variables and their associatedwait 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)