1. 7.1 Process Synchronization Background The Critical-Section Problem Synchronization Hardware Semaphores Classical Problems of Synchronization Monitors Java Synchronization

2. 7.2 Background Concurrent access to shared data may result in data inconsistency. Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes.

3. 7.3 Bounded Buffer public class BoundedBuffer { public void enter(Object item) { // producer calls this method } public Object remove() { // consumer calls this method } // potential race condition on count private int count; }

4. 7.4 enter() Method // producer calls this method public void enter(Object item) { while (count == BUFFER_SIZE) ; // do nothing // add an item to the buffer ++count; buffer[in] = item; in = (in + 1) % BUFFER_SIZE; }

5. 7.5 remove() Method // consumer calls this method public Object remove() { Object item; while (count == 0) ; // do nothing // remove an item from the buffer --count; item = buffer[out]; out = (out + 1) % BUFFER_SIZE; return item; }

6. 7.6 Issues count++  load count in register; register  register +1; store register in count ; count : similarly count is a shared variable; the effect of count++ and count– is imprevisible

7. 7.7 Critical Section (or Region) Critical Section  part of code: when one process is executing it, no other process may be in it

8. 7.8 Critical-Section Requierements 1.Mutual Exclusion. If process Pi is executing in its critical section, then no other processes can be executing in their critical sections. 2.Progress. If no process is executing in its critical section and there exist some processes that wish to enter their critical section, then the selection of the processes that will enter the critical section next cannot be postponed indefinitely. 3.Bounded Waiting. A bound must exist on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted. Assume that each process executes at a nonzero speed No assumption concerning relative speed of the n processes.

9. 7.9 Worker Thread public class Worker extends Thread { public Worker(String n, int i, MutualExclusion s) { name = n; id = i; shared = s; } public void run() { /* see next slide */ } private String name; private int id; private MutualExclusion shared; }

10. 7.10 run() Method of Worker Thread public void run() { while (true) { shared.enteringCriticalSection(id); // in critical section code shared.leavingCriticalSection(id); // out of critical section code }

11. 7.11 MutualExclusion Abstract Class public abstract class MutualExclusion { public static void criticalSection() { // simulate the critical section } public static void nonCriticalSection() { // simulate the non-critical section } public abstract void enteringCriticalSection(int t); public abstract void leavingCriticalSection(int t); public static final int TURN_0 = 0; public static final int TURN_1 = 1; }

12. 7.12 Testing Each Algorithm public class TestAlgorithm { public static void main(String args[]) { MutualExclusion alg = new Algorithm_1(); Worker first = new Worker("Runner 0", 0, alg); Worker second = new Worker("Runner 1", 1, alg); first.start(); second.start(); }

13. 7.13 Algorithm 1 public class Algorithm_1 extends MutualExclusion { public Algorithm_1() { turn = TURN_0; } public void enteringCriticalSection(int t) { while (turn != t) Thread.yield(); } public void leavingCriticalSection(int t) { turn = 1 - t; } private int turn; } PROGRESS – is not satisfied (consumer and producer must alternate).

14. 7.14 Algorithm 2 public class Algorithm_2 extends MutualExclusion { public Algorithm_2() { flag[0] = false; flag[1] = false; } public void enteringCriticalSection(int t) { // see next slide } public void leavingCriticalSection(int t) { flag[t] = false; } private boolean[] flag = new boolean[2]; }

15. 7.15 Algorithm 2 – enteringCriticalSection() public void enteringCriticalSection(int t) { int other = 1 - t; flag[t] = true; // I want to enter in the critical section while (flag[other] == true) Thread.yield(); } Problem: what if both set flag[t]=true ?

16. 7.16 Algorithm 3 public class Algorithm_3 extends MutualExclusion { public Algorithm_3() { flag[0] = false; flag[1] = false; turn = TURN_0; } public void enteringCriticalSection(int t) {/* see next slides */ } public void leavingCriticalSection(int t) {{/* see next slides */ } private volatile int turn; private volatile boolean[] flag = new boolean[2]; }

17. 7.17 Algorithm 3 – enteringCriticalSection() public void enteringCriticalSection(int t) { int other = 1 - t; flag[t] = true; turn = other; while ( (flag[other] == true) && (turn == other) ) Thread.yield(); }

18. 7.18 Algo. 3 – leavinging Critical Section() public void leavingCriticalSection(int t) { flag[t] = false; }

19. 7.19 Synchronization Hardware public class HardwareData { public HardwareData(boolean v) { data = v; } public boolean get() { return data; } public void set(boolean v) { data = v; } private boolean data; }

20. 7.20 Test-and-Set Instruction (mimicked in Java) public class HardwareSolution { public static boolean testAndSet(HardwareData target) { HardwareData temp = new HardwareData(target.get()); target.set(true); return temp.get(); }

21. 7.21 Thread using Test-and-Set HardwareData lock = new HardwareData(false); while (true) { while (HardwareSolution.testAndSet(lock)) Thread.yield(); // do nothing // now in critical section code lock.set(false); // out of critical section }

22. 7.22 Swap instruction public static void swap(HardwareData a, HardwareData b) { HardwareData temp = new HardwareData(a.get()); a.set(b.get()); b.set(temp.get()); }

23. 7.23 Thread using Swap HardwareData lock = new HardwareData(false); HardwareData key = new HardwareData(true); while (true) { key.set(true); do { HardwareSolution.swap(lock,key); } while (key.get() == true); // now in critical section code lock.set(false); // out of critical section }

24. 7.24 Semaphore- simple version Synchronization tool that does not require busy waiting. Semaphore S – integer variable (this is the simple version; still requires busy waiting) can only be accessed via two indivisible (atomic) operations P (S): while S  0 do no-op; S--; V(S): S++; P (probieren –in dutch) is also called wait. V (verhoegen- in dutch) is also called signal.

25. 7.25 Semaphore as General Synchronization Tool Semaphore S; // initialized to 1 P(S); CriticalSection() V(S);

26. 7.26 Semaphore: Counter + Queue P(S) { if (value < = 0) { add this process to list block() } value--; } V(S) { value++; if (value > 0) { remove a process P from list wakeup(P); }

27. 7.27 Synchronization Using Semaphores public class FirstSemaphore { public static void main(String args[ ]) { Semaphore sem = new Semaphore(1); Worker[] bees = new Worker[5]; for (int i = 0; i < 5; i++) bees[i] = new Worker(sem, "Worker " + (new Integer(i)).toString() ); for (int i = 0; i < 5; i++) bees[i].start(); }

28. 7.28 Worker Thread public class Worker extends Thread { public Worker(Semaphore s, String n) { sem = s; name=n;} public void run() { while (true) { sem.P(); // in critical section sem.V(); // out of critical section } private Semaphore sem; private String name; }

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

30. 7.30 Two Types of Semaphores Counting semaphore – integer value can range over a finite domain. Binary semaphore – integer value can range only between 0 and 1; can be simpler to implement.

31. 7.31 Classical Problems of Synchronization Bounded-Buffer Problem (Producer-Consumer Problem) Readers and Writers Problem Dining-Philosophers Problem

32. 7.32 Bounded-Buffer Problem public class BoundedBuffer { public BoundedBuffer() { /* see next slides */ } public void enter() { /* see next slides */ } public Object remove() { /* see next slides */ } private static final int BUFFER_SIZE = 2; private Semaphore mutex; private Semaphore empty; private Semaphore full; private int in, out; private Object[] buffer; }

33. 7.33 Bounded Buffer Constructor public BoundedBuffer() { // buffer is initially empty count = 0; in = 0; out = 0; buffer = new Object[BUFFER_SIZE]; mutex = new Semaphore(1); empty = new Semaphore(BUFFER_SIZE); // how many empty slots full = new Semaphore(0); //how many full slots }

34. 7.34 enter() Method public void enter(Object item) { empty.P(); mutex.P(); // add an item to the buffer buffer[in] = item; in = (in + 1) % BUFFER_SIZE; mutex.V(); full.V(); }

35. 7.35 remove() Method public Object remove() { full.P(); mutex.P(); // remove an item from the buffer Object item = buffer[out]; out = (out + 1) % BUFFER_SIZE; mutex.V(); empty.V(); return item; }

36. 7.36 Readers-Writer Problem Readers do not do any harm. Writers do  they have critical section, i.e., they cannot access the DataBase at the same time with any other thread. Requierement: a reader can wait only if a writer has been granted access to the critical section.

37. 7.37 Readers-Writers Problem: Reader public class Reader extends Thread { public Reader(Database db) { server = db; } public void run() { int c; while (true) { c = server.startRead(); // now reading the database c = server.endRead(); } private Databaseserver; }

38. 7.38 Readers-Writers Problem: Writer public class Writer extends Thread { public Writer(Database db) { server = db; } public void run() { while (true) { server.startWrite(); // now writing the database server.endWrite(); } private Databaseserver; }

39. 7.39 Readers-Writers Problem (cont) public class Database { public Database() { readerCount = 0; mutex = new Semaphore(1); db = new Semaphore(1); } public int startRead() { /* see next slides */ } public int endRead() { /* see next slides */ } public void startWrite() { /* see next slides */ } public void endWrite() { /* see next slides */ } private int readerCount; // number of active readers Semaphore mutex; // controls access to readerCount Semaphore db; // controls access to the database }

40. 7.40 startRead() Method public int startRead() { mutex.P(); ++readerCount; // if I am the first reader tell all others // that the database is being read if (readerCount == 1) db.P(); // lock the DB so that a writer does not enter mutex.V(); // allow other readers return readerCount; }

41. 7.41 endRead() Method public int endRead() { mutex.P(); --readerCount; // if I am the last reader tell all others // that the database is no longer being read if (readerCount == 0) db.V(); // unlock the DB for writers mutex.V(); return readerCount; }

42. 7.42 Writer Methods public void startWrite() { db.P(); } public void endWrite() { db.V(); }

43. 7.43 Dining-Philosophers Problem Shared data Semaphore chopStick[] = new Semaphore[5];

44. 7.44 Dining-Philosophers Problem (Cont.) Philosopher i: while (true) { // get left chopstick chopStick[i].P(); // get right chopstick chopStick[(i + 1) % 5].P(); // eat for awhile //return left chopstick chopStick[i].V(); // return right chopstick chopStick[(i + 1) % 5].V(); // think for awhile }  May lead to deadlock.

45. 7.45 Monitors A monitor is a high-level abstraction that provides thread safety. Only one thread may be active within the monitor at a time. It’s basically a collection of routines; only one thread may execute any of the routines in the monitor at a time. monitor monitor-name { // variable declarations public p1(…) { … } public p2(…) { … }

46. 7.46 Condition Variables condition x, y; A thread that invokes x.wait is suspended until another thread invokes x.signal

47. 7.47 Monitor with condition variables

48. 7.48 Solution to Dining Philosophers monitor diningPhilosophers { int[] state = new int[5]; static final int THINKING = 0; static final int HUNGRY = 1; static final int EATING = 2; condition[] self = new condition[5]; public diningPhilosophers { for (int i = 0; i < 5; i++) state[i] = THINKING; } public entry pickUp(int i) { /* see next slides */ } public entry putDown(int i) { /* see next slides */ } private test(int i) {/* see next slides */ } }

49. 7.49 pickUp() Procedure public entry pickUp(int i) { state[i] = HUNGRY; test(i); // check if neighbors are eating or not // if they are not, state[I]  EATING in test(i) if (state[i] != EATING) self[i].wait; }

50. 7.50 putDown() Procedure public entry putDown(int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); test((i + 1) % 5); }

51. 7.51 test() Procedure private test(int i) { if ( (state[(i + 4) % 5] != EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5] != EATING) ) { state[i] = EATING; self[i].signal; }

52. 7.52 Java Synchronization Synchronized, wait(), notify() statements Multiple Notifications Block Synchronization Java Semaphores Java Monitors

53. 7.53 synchronized Statement Every object has a lock associated with it. Calling a synchronized method requires “owning” the lock. If a calling thread does not own the lock (another thread already owns it), the calling thread is placed in the wait set for the object’s lock. The lock is released when a thread exits the synchronized method.

54. 7.54 Entry Set

55. 7.55 synchronized enter() Method public synchronized void enter(Object item) { while (count == BUFFER_SIZE) Thread.yield(); ++count; buffer[in] = item; in = (in + 1) % BUFFER_SIZE; }

56. 7.56 synchronized remove() Method public synchronized Object remove() { Object item; while (count == 0) Thread.yield(); --count; item = buffer[out]; out = (out + 1) % BUFFER_SIZE; return item; }

57. 7.57 The wait() Method When a thread calls wait(), the following occurs: - the thread releases the object lock. - thread state is set to blocked. - thread is placed in the wait set.

58. 7.58 Entry and Wait Sets

59. 7.59 The notify() Method When a thread calls notify(), the following occurs: - selects an arbitrary thread T from the wait set. - moves T to the entry set. - sets T to Runnable. T can now compete for the object’s lock again.

60. 7.60 enter() with wait/notify Methods public synchronized void enter(Object item) { while (count == BUFFER_SIZE) try { wait(); } catch (InterruptedException e) { } } ++count; buffer[in] = item; in = (in + 1) % BUFFER_SIZE; notify(); }

61. 7.61 remove() with wait/notify Methods public synchronized Object remove() { Object item; while (count == 0) try { wait(); } catch (InterruptedException e) { } --count; item = buffer[out]; out = (out + 1) % BUFFER_SIZE; notify(); return item; }

62. 7.62 Multiple Notifications notify() selects an arbitrary thread from the wait set. *This may not be the thread that you want to be selected. Java does not allow you to specify the thread to be selected. notifyAll() removes ALL threads from the wait set and places them in the entry set. This allows the threads to decide among themselves who should proceed next. notifyAll() is a conservative strategy that works best when multiple threads may be in the wait set.

63. 7.63 Reader Methods with Java Synchronization public class Database { public Database() { readerCount = 0; dbReading = false; dbWriting = false; } public synchronized int startRead() { /* see next slides */ } public synchronized int endRead() { /* see next slides */ } public synchronized void startWrite() { /* see next slides */ } public synchronized void endWrite() { /* see next slides */ } private int readerCount; private boolean dbReading; private boolean dbWriting; }

64. 7.64 startRead() Method public synchronized int startRead() { while (dbWriting == true) { try { wait(); } catch (InterruptedException e) { } ++readerCount; if (readerCount == 1) dbReading = true; return readerCount; }

65. 7.65 endRead() Method public synchronized int endRead() { --readerCount if (readerCount == 0) dbReading = false; db.notifyAll(); return readerCount; }

66. 7.66 Writer Methods public void startWrite() { while (dbReading == true || dbWriting == true) try { wait(); } catch (InterruptedException e) { } dbWriting = true; } public void endWrite() { dbWriting = false; notifyAll(); }

67. 7.67 Block Synchronization Blocks of code – rather than entire methods – may be declared as synchronized. This yields a lock scope that is typically smaller than a synchronized method.

68. 7.68 Block Synchronization (cont) Object mutexLock = new Object();... public void someMethod() { // non-critical section synchronized(mutexLock) { // critical section } // non-critical section }

69. 7.69 Java Semaphores Java does not provide a semaphore, but a basic semaphore can be constructed using Java synchronization mechanism.

70. 7.70 Semaphore Class public class Semaphore { public Semaphore() { value = 0; } public Semaphore(int v) { value = v; } public synchronized void P() { /* see next slide */ } public synchronized void V() { /* see next slide */ } private int value; }

71. 7.71 P() Operation public synchronized void P() { while (value <= 0) { try { wait(); } catch (InterruptedException e) { } } value --; }

72. 7.72 V() Operation public synchronized void V() { ++value; notify(); }

73. 7.73 Solaris 2 Synchronization Solaris 2 Provides: - adaptive mutex (similar to a busy-waiting semaphore, but avoids some spinning if the process having the lock is blocked) - condition variables - semaphores - reader-writer locks

74. 7.74 Windows 2000 Synchronization Windows NT Provides: - mutex - critical sections - semaphores - event objects (similar to condition variables)