© 2004, D. J. Foreman 1 Monitors and Inter-Process Communication

© 2004, D. J. Foreman 2 Basic Concept  Consists of a lock and zero or more condition variables

© 2004, D. J. Foreman 3 The Dining Philosophers Philosopher (int i) { while (TRUE) {// Think (wait for forks) then Eat P (fork[i]); // test left fork P (fork[(i+1) mod 5]); // test right fork eat(); V (fork[(i+1) mod 5]); V (fork[i]); } semaphore fork[5] = (1,1,1,1,1); // create philosopher processes fork (philosopher, 1, 0); fork (philosopher, 1, 1); fork (philosopher, 1, 2); fork (philosopher, 1, 3); fork (philosopher, 1, 4);

© 2004, D. J. Foreman 4 One Solution philosopher (int i) { while (TRUE) {// Think (wait for forks) then Eat j = i % 2; P (fork [(i+j) mod 5]); P (fork [(i+1-j) mod 5]); eat(); V (fork [(i+1-j) mod 5]); V (fork [(i+j) mod 5]); } semaphore fork[5] = (1,1,1,1,1); fork (philosopher, 1, 0); fork (philosopher, 1, 1); fork (philosopher, 1, 2); fork (philosopher, 1, 3); fork (philosopher, 1, 4);

© 2004, D. J. Foreman 5 AND Synchronization  For n resources: R n  Some P i ->R j, maybe >1 in one critsec  order of P operations may cause deadlock  Using semaphores S i  P simultaneous (S 1, …, S n )

© 2004, D. J. Foreman 6 Simultaneous Semaphores P_sim (semaphore S, int N) {L1: if ( (S[0]>=1)&& … &&(S[N-1]>=1) ) { for (i=0; i<N; i++) S[i]--; } else { Enqueue the calling thread in the queue for the first S[i] where S[i]<1; The calling thread is blocked while it is in the queue; // When the thread is removed from the queue Goto L1; // this is an algorithm, not code! } V_sim (semaphore S, int N) {for (i=0; i<N; i++) {S[i]++; Dequeue all threads in the queue for S[i]; All such threads are now ready to run (but may be blocked again in Psimultaneous ); } else {} }

© 2004, D. J. Foreman 7 Dining Philosophers Re-visited Philosopher (int i) {while (TRUE) { // Think & Eat Psim (fork[i], fork [(i+1) mod 5]); eat(); Vsim (fork[i], fork [(i+1) mod 5]); } semaphore fork[5] = (1,1,1,1,1); fork(philosopher, 1, 0); fork(philosopher, 1, 1); fork(philosopher, 1, 2); fork(philosopher, 1, 3); fork(philosopher, 1, 4);

© 2004, D. J. Foreman 8 Mutex solutions-1  First attempt: int turn = 0; // initial value for turn (the semaphore) /* process 0 *//* processes 1 */ {while(turn != 0) no-op;{while(turn != 1) no-op; /* critical section*/ /* critical section*/ turn = 1; turn = 0; }} Strict alternation between two processes via use of shared variable “turn” Mutual exclusion achieved Two problems:  Performance determined by least active (slowest) process  If one process crashes outside of the critical section, the other will wait forever for the CS.

© 2004, D. J. Foreman 9 Mutex solutions-2  Second attempt: /* process 0 *//* processes 1 */ {flag[0] = true;{flag[1] = true; while(flag[1]) no-op;while(flag[0]) no-op; /* critical section*/ /* critical section*/ flag[0] = false;flag[1] = false; }} Crash outside CS will not indefinitely block other process  Mutual exclusion achieved Q: Is Deadlock caused by race to set flag[i]?

© 2004, D. J. Foreman 10 Correct (s/w) solution  See Dekker’s Algorithm: ■ Combines using the “turn” variable and flag[] variable. ■ Avoids mutual courtesy ■ “turn” guarantees mutual exclusion. ■ “flag[]” breaks strict alternation problem – if your flag is set to 1 and other flag is 0, then enter no matter what turn is. ■ In the event that a race causes flag[0] = flag[1] = 1, then there is no deadlock to get to the CS because turn will allow one of the processes to enter. ■ flag[i] is an indication of “intent” to enter.

© 2004, D. J. Foreman 11 Monitors  Look like C++ "classes" ■ encapsulation ■ private mutex (semaphore) variable ■ public interfaces  public interfaces use P, V for protection ■ acts like a "critical section"

© 2004, D. J. Foreman 12 Condition Variables (cv's)  Private to monitor  Access via: ■ wait() – suspends process ■ signal() – lets ONE process resume ■ queue() – TRUE if #waiters on cv > 0  2 approaches ■ Hoare – p1 waiting, p0 signals, p1 starts now ■ Mesa (Hansen) – p1 waiting, p0 signals and continues to run, p1 re-checks when p0 ends fewer context switches

© 2004, D. J. Foreman 13 Comparison  Hoare semantics if (R is held) R.wait(); //proceed  Mesa semantics while (R held) R.wait(); // forces re-try //proceed

© 2004, D. J. Foreman 14 Mesa vs. Hoare  Mesa: signaler keeps lock, waking thread must wait on acquire  Hoare: signaler releases lock, waking thread acquires and runs

© 2004, D. J. Foreman 15 IPC  Pipes ■ anonymous limited to parent-child due to file reference child inherits pipe-end as an open file ■ named pipe is opened with a name names are system-wide managed like files  Message passing ■ send() & receive() ■ synchronous & asynchronous

© 2004, D. J. Foreman 16 Notes on Java  The JVM ■ uses monitors for mutual exclusion ■ provides wait and notify for cooperation

© 2004, D. J. Foreman 17 Condition Variables vs Semaphores CV'sSemaphores Only in monitorsAnywhere BUT monitors Wait always blocksWait blocks if count>0 Signal releases a blocked thread or does nothing Signal releases a blocked thread or increments count Either caller or released thread continues (Hoare vs Mesa) Both continue