Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo.

Similar presentations


Presentation on theme: "1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo."— Presentation transcript:

1 1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo

2 2 Mutual Exclusion with Swap Initially, s == false; entry () { bool spin = true; Swap(spin, s); while (spin) Swap(spin, s); } exit() { s = false; }

3 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 4 Semaphore Implementation Define a semaphore as a record typedef 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 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 6 Critical Sections with Semaphores semaphore mutex = 1; entry() P(mutex); exit() V(mutex); For mutual exclusion, initialize semaphore to 1.

7 7 Semaphore as a General Synchronization Tool Execute B in P j only after A executed in P i Use semaphore flag initialized to 0 Code: P i P j   AP(flag) V(flag)B

8 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 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 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 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 P 0 P 1 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 12 Readers-Writers Problem Given a database Can have multiple “readers” at a time don’t ever modify database Only one “writer” will modify database The problem has many variation

13 13 Readers-Writers Problem Semaphore Solution Shared data semaphore mutex = 1, wrt = 1; int readcount = 0; Writer Process writeEnter () { P(wrt); } writeExit () { V(wrt); }

14 14 Reader Process readEnter () { P(mutex); readcount++; if (readcount == 1) P(wrt); V(mutex); } readExit() { P(mutex); readcount--; if (readcount == 0) V(wrt); V(mutex); }

15 15 Dining-Philosophers Problem Shared data semaphore chopstick[5]; Initially all values are 1

16 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 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 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 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 20 Monitors monitor monitor-name { shared variable declarations procedure body P1 (…) {... } procedure body P2 (…) {... } procedure body Pn (…) {... } { initialization code }

21 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 22 Schematic View of a Monitor

23 23 Monitor With Condition Variables

24 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 25 Monitor Solution to Critical Section Just make the critical section a monitor routine!

26 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 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 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 29 cond->Wait(mutex): nc++; V(mutex); P(c); P(mutex); cond->Signal(): if (nc > 0) { nc--; V(c); } Implementing Monitors using Semaphores

30 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


Download ppt "1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo."

Similar presentations


Ads by Google