1

Semaphores and Monitors

CIS450 Winter 2003

Professor Jinhua Guo

2

Mutual Exclusion with Swap

Initially, s == false;

entry () {bool spin = true;Swap(spin, s);while (spin)

Swap(spin, s);}

exit() {s = false;

}

3

Semaphores (Dijkstra)

• Synchronization tool that does not require busy waiting.

• Semaphore is an object contains a (private) integer value and 2 operations.– P operation, also called Down or Wait

• Take a resource

– V operation, also called Up or Signal• Release a resource

• Semaphores are “resource counters”.

4

Semaphore Implementation

• Define a semaphore as a recordtypedef struct { int value; struct process *L;} semaphore;

• Assume two simple operations:– block(), suspends the process that invokes it.– wakeup(P), changes the thread from the waiting state

to the ready state.

5

Implementation• Semaphore operations now defined as

P(S):S.value--;if (S.value < 0) {

add this process to S.L;block();

}

V(S): S.value++;if (S.value <= 0) {

remove a process P from S.L;wakeup(P);

}• The P and V operations are atomic.

6

Critical Sections with Semaphores

semaphore mutex = 1; entry()

P(mutex);exit()

V(mutex);

• For mutual exclusion, initialize semaphore to 1.

7

Semaphore as a General Synchronization Tool

• Execute B in Pj only after A executed in Pi

• Use semaphore flag initialized to 0

• Code:

Pi Pj A P(flag)

V(flag) B

8

Bounded Buffer Problem

• There is one Buffer object used to pass objects from producers to consumers. The problem is to allow concurrent access to the Buffer by producers and consumers, while ensuring that 1. The shared Buffer data structure is not screwed up

by race conditions in accessing it.

2. Consumers don't try to remove objects from Buffer when it is empty.

3. Producers don't try to add objects to the Buffer when it is full.

9

Bounded Buffer (1 producer, 1 consumer)

Producer()while (1) {

produce message m;P(empty);buf[rear] = m;rear = rear “+”1;V(full);

}

Consumer () while (1) {

P(full);m = buf[front];front = front “+” 1;V(empty);consume m;

}

char buf[n], int front = 0, rear = 0;semaphore empty = n, full = 0;

10

Bounded Buffer (multiple producers and consumers)

Producer()while (1) {

produce message m;P(empty);P(mutex);buf[rear] = m;rear = rear “+”1;V(mutex);V(full)

}

Consumer () while (1) {

P(full);P(mutex);m = buf[front];front = front “+” 1;V(mutex);V(empty);consume m;

}

char buf[n], int front = 0, rear = 0;semaphore empty = n, full = 0, mutex = 1;

11

Deadlock and Starvation

• Deadlock – two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes.Let S and Q be two semaphores initialized to 1

P0 P1

P(S); P(Q);P(Q); P(S); V(S); V(Q);V(Q); V(S);

• Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended.

12

Readers-Writers Problem

• Given a databaseCan have multiple “readers” at a time

don’t ever modify database

Only one “writer”

will modify database

• The problem has many variation

13

Readers-Writers Problem Semaphore Solution

• Shared data

semaphore mutex = 1, wrt = 1;int readcount = 0;

• Writer ProcesswriteEnter () {

P(wrt);}

writeExit () {V(wrt);

}

14

• Reader ProcessreadEnter () {

P(mutex);readcount++;if (readcount == 1) P(wrt);V(mutex);

}

readExit() {P(mutex);readcount--;if (readcount == 0) V(wrt);V(mutex);

}

15

Dining-Philosophers Problem

• Shared data

semaphore chopstick[5];

Initially all values are 1

16

Dining-Philosophers Problem• Philosopher i:

do {P(chopstick[i])P(chopstick[(i+1) % 5])

…eat …

V(chopstick[i]);V(chopstick[(i+1) % 5]);

…think …

} while (1);

17

Dining-Philosophers Problem(Deadlock Free)

• Philosopher i:do { if (i ! = 0) {

P(chopstick[i]); P(chopstick[i+1]);… eat …

V(chopstick[i]); V(chopstick[i+1]); } else {

P(chopstick[1]); P(chopstick[0]);… eat …

V(chopstick[1]); V(chopstick[0]); }

…think …

} while (1);

18

Problems with Semaphores

• Used for 2 independent purposes– Mutual exclusion– Condition Synchronization

• Hard to get right– Small mistake easily leads to deadlock

May want to separate mutual exclusion, condition synchronization

19

Monitors (Hoare)

• Abstract Data Type– Consists of vars and procedures, like C++ class.– 3 key differences from a regular class:

• Only one thread in monitor at a time (mutual exclusion is automatic);

• Special type of variable allowed, called “condition variable”

– 3 special ops allowed only on condition variables: wait, signal, broadcast

• No public data allowed (must call methods to effect any change)

20

Monitorsmonitor monitor-name{

shared variable declarationsprocedure body P1 (…) {

. . .}procedure body P2 (…) {

. . .} procedure body Pn (…) {

. . .} {

initialization code}

}

21

Monitors

• To allow a process to wait within the monitor, a condition variable must be declared, as

condition x, y, cond;• Given a condition variable “cond”

– cond.wait():• thread is put on queue for “cond”, goes to sleep

– cond.signal():• if queue for “cond” not empty, wakeup one thread

– cond.broadcast• wakeup all threads waiting on queue for “cond”

22

Schematic View of a Monitor

23

Monitor With Condition Variables

24

Semantics of Signal

• Signal and Wait (Hoare)– signaller immediately gives up control– thread that was waiting executes

• Signal and Continue (Java, Pthread, Mesa)– signaller continues executing– thread that was waiting put on ready queue– when thread actually gets to run

• State may have changed! Use “while”, not “if”

25

Monitor Solution to Critical Section

• Just make the critical section a monitor routine!

26

Readers/Writers Solution Using Monitors

• Similar idea to semaphore solution– Simpler, because don’t worry about mutex

• When can’t get into database, wait on appropriate condition variable

• When done with database, signal others

Note: can’t just put code for “reading database” and code for “writing database” in the monitor (could’t have >1 reader)

27

Difference between Monitors and Semaphores

• Monitors enforce mutual exclusion

• P() vs Wait– P blocks if value is 0, Wait always blocks

• V() vs Signal– V either wakes up a thread or increments

value– Signal only has effect if a thread waiting

• Semaphores have “memory”

28

Implementing Monitors using Semaphores

• Shared vars:– semaphore mutex = 1(one per monitor)– semaphore c = 0; (one per condition var)– int nc = 0; (one per condition var)

• Monitor entry: P(mutex);

• Monitor exit: V(mutex);

29

• cond->Wait(mutex):nc++;V(mutex);P(c);P(mutex);

• cond->Signal():if (nc > 0) {

nc--;V(c);

}

Implementing Monitors using Semaphores

30

Java-style monitors

• Integrated into the class mechanism– Annotation “synchronized” can be applied to a

member function• This function executes with implicit mutual

exclusion

– Wait, Signal, and Broadcast are called mon wait, notify, and notifyAll, respectively