1. Silberschatz, Galvin and Gagne  2002 7.1 Operating System Concepts Chapter 6: Synchronization Background The Critical-Section Problem Synchronization Hardware Semaphores Classical Problems of Synchronization Monitors

2. Silberschatz, Galvin and Gagne  2002 7.2 Operating System Concepts Processes Communication Cooperating process is one that can affect or be affected by other processes executing in the system. Processes can communicate in two ways: 1. Message Passing  Send(), Receive() 2. Shared memory  Concurrent access to shared data may result in data inconsistency. Various mechanism used to ensure the orderly execution of cooperating processes are discussed in the chapter.

3. Silberschatz, Galvin and Gagne  2002 7.3 Operating System Concepts Producer-Consumer Problem (Using Bounded-Buffer and Shared Data ) #define BUFFER_SIZE 10 Typedef struct {... } item; item buffer[BUFFER_SIZE]; int in = 0; int out = 0; A producer and a consumer are used to execute the process communication in: points to the next free position in the buffer out: points to the first full position in the buffer

4. Silberschatz, Galvin and Gagne  2002 7.4 Operating System Concepts Producer-Consumer Problem (Using Bounded-Buffer and Shared Data ) item nextProduced; while (1) { while (((in + 1) % BUFFER_SIZE) == out) ; /* do nothing */ ----- buffer is full buffer[in] = nextProduced; in = (in + 1) % BUFFER_SIZE; } item nextConsumed; while (1) { while (in == out) ; /* do nothing */----buffer is empty nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; } Producer Consumer allows at most N – 1 items in the buffer at the same time

5. Silberschatz, Galvin and Gagne  2002 7.5 Operating System Concepts A solution where all N buffers are used is not simple. Suppose that we modify the producer-consumer code by adding a variable counter, initialized to 0 and incremented each time when a new item is added to the buffer Producer-Consumer Problem (Using Bounded-Buffer and Shared Data ) item nextProduced; while (1) { while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = nextProduced; in = (in + 1) % BUFFER_SIZE; counter++; } item nextConsumed; while (1) { while (counter == 0) ; /* do nothing */ nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; }

6. Silberschatz, Galvin and Gagne  2002 7.6 Operating System Concepts Producer-Consumer Problem The producer and consumer routines may not function correctly when executed concurrently. The statements counter++; counter--; must be performed atomically to avoid errors. Atomic operation means an operation that completes its calculations without interruption. If they are not performed atomically, what will happen?

7. Silberschatz, Galvin and Gagne  2002 7.7 Operating System Concepts Producer-Consumer Problem ( Bounded-Buffer ) Suppose that the value of counter is currently 5. When the producer and consumer processes execute the statements “count++” and “count--” concurrently, the correct result of counter should be 5. However, you may get 4, 5, or 6. If both the producer and consumer attempt to update the buffer concurrently, the assembly language statements may get interleaved. Interleaving depends upon how the producer and consumer processes are scheduled.

8. Silberschatz, Galvin and Gagne  2002 7.8 Operating System Concepts Producer-Consumer Problem The statement “count++” may be implemented in machine language as: register1 = counter register1 = register1 + 1 counter = register1 The statement “count -- ” may be implemented as: register2 = counter register2 = register2 – 1 counter = register2

9. Silberschatz, Galvin and Gagne  2002 7.9 Operating System Concepts Producer-Consumer Problem ( Bounded-Buffer ) Counter is initially 5. One possible interleaving is: T0: producer: register1 = counter (register1 = 5) T1: producer: register1 = register1 + 1 (register1 = 6) T2: consumer: register2 = counter (register2 = 5) T3: consumer: register2 = register2 – 1 (register2 = 4) T4: producer: counter = register1 (counter = 6) T5: consumer: counter = register2 (counter = 4) The final value of count is 4. (wrong) If we reverse the order of the statements of T4 and T5, The final value of count is 6 (wrong), where the correct result should be 5.

10. Silberschatz, Galvin and Gagne  2002 7.10 Operating System Concepts Race Condition Race condition: several processes access and manipulate the same data concurrently and the outcome of the execution depends on the particular order in which the access takes place. To prevent race conditions, concurrent processes must be synchronized. In the previous example, we must ensure that only one process at a time can be manipulating the variable counter (without other processes’ intervention – atomic).

11. Silberschatz, Galvin and Gagne  2002 7.11 Operating System Concepts The Critical-Section Problem n processes want to use some shared data concurrently Each process has a segment of code, called critical section (CS), in which the shared data is accessed.  counter++ in producer process  counter-- in consumer process CS Problem – ensure that when one process is executing in its critical section, no other process is allowed to execute in its critical section (mutually exclusive). Each process must request the permission to enter its CS.

12. Silberschatz, Galvin and Gagne  2002 7.12 Operating System Concepts The Critical-Section Problem (cont.) The section of code implementing the request for CS is called the entry section The critical section (CS) might be followed by an exit section The remaining code is the remainder section The critical section problem is to design a protocol that the processes can use to cooperate so that their results will not depend on the order in which their executions are interleaved (possibly on many processors) do { entry section critical section exit section remainder section } while (1);

13. Silberschatz, Galvin and Gagne  2002 7.13 Operating System Concepts 1. Mutual Exclusion: If process P i 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 some processes wish to enter their critical section, then only those processes that are not executing in their remainder section can participate in the decision on which will enter its critical section next, and this selection cannot be postponed indefinitely. 3. Bounded Waiting: After a process has made a request to enter its critical section and before that request is granted, there exists a bound on the number of times that other processes are allowed to enter their critical sections. A solution to CS problem must satisfy the following three requirements: Solution to Critical-Section Problem

14. Silberschatz, Galvin and Gagne  2002 7.14 Operating System Concepts Types of solutions to CS problem Algorithm solutions (user-level)  For two process: three algorithms  For n process: Bakery algorithm Assume that the basic machine-language instructions (such as load, store, and test) are executed atomically. Hardware solutions  test-and-set instruction  Swap instruction Semaphore Monitor

15. Silberschatz, Galvin and Gagne  2002 7.15 Operating System Concepts Initial Attempts to Solve Problem n Only 2 processes, P 0 and P 1 n General structure of process P i (other process P j ) do { entry section critical section exit section remainder section } while (1); n Processes may share some common variables to synchronize their actions.

16. Silberschatz, Galvin and Gagne  2002 7.16 Operating System Concepts Algorithm 1 n Shared variable: F int turn; //initially turn = 0 or turn = 1 n If turn == i  P i is allowed to execute in its CS. n Process P i do { while (turn != i) ; //wait till turn==i CS turn = j; //release turn to j RS } while (1); entry section exit section

17. Silberschatz, Galvin and Gagne  2002 7.17 Operating System Concepts Algorithm 1 Satisfy mutual exclusion, but not progress if turn==0 and P 1 is ready to enter its CS, P 1 cannot do so, even though P 0 may be in its RS.  no progress 1. P 0 enters, then exits from CS (turn =>1). Now, It is in its RS. 2. Because turn==1, P 1 enters, then exits from CS (turn =>0). P 1 finishes this RS. 3. P 1 wants to enter CS again. Now turn==0, P 1 have to wait for P 0 (even though P 0 is in its RS). Process P i do { while (turn != i) ; CS //now, turn=i turn = j; RS } while (1); Process P j do { while (turn != j) ; CS //now, turn=j turn = i; RS } while (1);

18. Silberschatz, Galvin and Gagne  2002 7.18 Operating System Concepts Algorithm 2 n Algorithm 1 does not retain sufficient information about the state of each process. n Shared variables F boolean flag[2]; //initially flag [0] = flag [1] = false n flag [i] = true  P i intends to enter CS n Process P i do { flag[i] := true; //show my intention while (flag[j]) ; // wait till P j don’t want to enter its CS CS flag [i] = false; //show my exit RS } while (1);

19. Silberschatz, Galvin and Gagne  2002 7.19 Operating System Concepts Algorithm 2 Satisfy mutual exclusion, but not progress To illustrate this problem, we consider the following example sequence ： T 0 ： P 0 sets flag[0] = true T 1 ： P 1 sets flag[1] = true Now P 0 and P 1 are looping forever in their respective while statements ( while (flag[j]) and while (flag[i]) ). Process P i do { flag[i] := true; while (flag[j]) ; CS flag [i] = false; RS } while (1); Process P j do { flag[j] := true; while (flag[i]) ; CS flag [j] = false; RS } while (1);

20. Silberschatz, Galvin and Gagne  2002 7.20 Operating System Concepts Algorithm 3 (Peterson’s Solution) Combine the idea of algorithms 1 and 2 n Shared variable: F int turn; //initially turn = 0 or turn = 1  Boolean flag [2]; //initially flag[0]=flag[1]=false Process P i ： do { flag [i]:= true; //show my intention turn = j; // give turn to process j, other process first while (flag [j] and turn = =j) ; // wait till process CS j exit or turn==i flag [i] = false; //show my exit RS } while (1); entry section exit section

21. Silberschatz, Galvin and Gagne  2002 7.21 Operating System Concepts Algorithm 3 do { flag [i]:= true; turn = j; while (flag [j] and turn ==j) ; CS flag [i] = false; RS } while (1); do { flag [j]:= true; turn = i; while (flag [i] and turn ==i) ; CS flag [j] = false; RS } while (1); 1. If only one process wants to enter CS, it can enter. 2. If both processes want to enter CS concurrently, then flag[i]=true=flag[j]. Now, the value of turn will determine which process can leave the while loop. If turn is set to both i and j at the same time, only one of these assignments will last; the other will occur, but be overwritten immediately ( – Explain). So, only one process can enter CS  Only one process can enter CS, so mutual exclusion is preserved Process P i Process P j

22. Silberschatz, Galvin and Gagne  2002 7.22 Operating System Concepts Algorithm 3 do { flag [i]:= true; turn = j; while (flag [j] and turn ==j) ; CS flag [i] = false; RS } while (1); do { flag [j]:= true; turn = i; while (flag [i] and turn ==i) ; CS flag [j] = false; RS } while (1); 1. If P i is in RS, then flag[i]=false. So P j can enter CS if it wants to (ignore turn).  P i won’t affect the CS entrance of P j 2. If both processes want to enter CS concurrently, then flag[i]=true=flag[j]. Now, the value of turn will determine which process can leave the while loop. If turn is set to both i and j at the same time, only one of these assignments will last; the other will occur, but be overwritten immediately (turn can be either i or j, but not both. If turn=i, P i will enter its CS.) So, P i (or P j ) can enter CS in limited time.  Progress is preserved Process P i Process P j

23. Silberschatz, Galvin and Gagne  2002 7.23 Operating System Concepts Algorithm 3 do { flag [i]:= true; turn = j; while (flag [j] and turn ==j) ; CS flag [i] = false; RS } while (1); do { flag [j]:= true; turn = i; while (flag [i] and turn ==i) ; CS flag [j] = false; RS } while (1); 1. If both processes want to enter CS concurrently, then flag[i]=true=flag[j]. If turn=i, P i enters its CS and P j waits in its while loop. Then P i exits and sets flag[i] to false, and finally ends. Now, if P i wants to re-enter immediately, it will set flag[i]= true and execute “turn=j”. P i will wait in its while loop because flag[j]= true and turn=j. Now, P j can enter its CS because turn=j. Hence, P j can enter its CS after at most one entry of P i (wait one time at most)  bounded waiting is preserved Process P i Process P j

24. Silberschatz, Galvin and Gagne  2002 7.24 Operating System Concepts Bakery Algorithm n Before entering its critical section, process receives a number. Holder of the smallest number enters the critical section. n If processes P i and P j receive the same number, if i < j, then P i is served first; else P j is served first. n The numbering scheme always generates numbers in increasing order of enumeration; i.e., 1,2,3,3,3,3,4,5... Critical section problem for n processes

25. Silberschatz, Galvin and Gagne  2002 7.25 Operating System Concepts Types of solutions to CS problem Algorithm solutions (user-level)  For two process: three algorithms  For n process: Bakery algorithm Assume that the basic machine-language instructions (such as load, store, and test) are executed atomically. Hardware solutions  test-and-set instruction  Swap instruction Semaphore Monitor

26. Silberschatz, Galvin and Gagne  2002 7.26 Operating System Concepts Synchronization Hardware Hardware features can make the programming task easier and improve system efficiency. Test and modify the content of a word atomically. boolean TestAndSet (boolean &target) { boolean rv = target; target = true; return rv; } Shared data: boolean lock; // initialized to false lock == true  do not enter lock == false  free to enter Process P i do { while (TestAndSet(lock)) ; //check, wait and lock CS lock = false; //unlock RS }

27. Silberschatz, Galvin and Gagne  2002 7.27 Operating System Concepts Synchronization Hardware Swap two variables atomically. void Swap(boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp; } Shared data : boolean lock; //initialized to false lock == true  key==true  do not enter lock == false  key==false  free to enter Process P i do { key = true; while (key == true) Swap(&lock, &key); //check, wait and lock CS lock = false; //unlock RS }

28. Silberschatz, Galvin and Gagne  2002 7.28 Operating System Concepts Process P i do { while (TestAndSet(lock)) ; //check, wait and lock CS lock = false; //unlock RS } Process P j do { while (TestAndSet(lock)) ; //check, wait and lock CS lock = false; //unlock RS } 1. When both processes want to enter CS concurrently If P i goes first (now, lock=false), it will set lock to true and enter its CS. Then, P j have to wait till lock is free by P i.  Mutual exclusion is preserved 2. Assume P i has entered its CS and P j waited in its while loop. If P i exits and immediately want to re-enter its CS, it might goes first so P j will keep waiting again (possible starvation).  Bounded waiting is not satisfied Synchronization Hardware - Wrong

29. Silberschatz, Galvin and Gagne  2002 7.29 Operating System Concepts Process P i do { waiting[i] = true; //show my intention key = true; while ( waiting[i] && key ) key = TestAndSet(lock); //wait till get key waiting[i] = false; // P i got key CS j = (i+1) % n; while( (j != i) && !waiting[j] ) j = (j+1) % n; if ( j == i ) lock = false; else waiting[j] = false; RS } Synchronization Hardware - Correct boolean lock; //initialized to false boolean waiting[n]; //initialized to false waiting[i] = true  P i intended to enter its CS and is getting key waiting[i] = false  P i intended to enter its CS and got the key or P i unintended

30. Silberschatz, Galvin and Gagne  2002 7.30 Operating System Concepts do { waiting[i] = true; //show my intention key = true; while ( waiting[i] && key ) key = TestAndSet(lock); //wait till get key waiting[i] = false; // P i got key CS j = (i+1) % n; while( (j != i) && !waiting[j] ) j = (j+1) % n; if ( j == i ) lock = false; else waiting[j] = false; RS } Synchronization Hardware - Correct 1. The first process to execute TestAndSet will find key=false and exit while loop; all others must wait  mutual exclusion 2. A process exiting CS sets lock to false or sets waiting[j] to false. Both allow a process waiting to enter its CS to proceed.  Progress 3. P 0 exits CS, then set waiting[1] to false to allow P 1 enters CS. P 1 exits CS, then set waiting[2] to false to allow P 2 enters CS… Scan the waiting array in the cyclic order  Bounded waiting

31. Silberschatz, Galvin and Gagne  2002 7.31 Operating System Concepts Types of solutions to CS problem Algorithm solutions (user-level)  For two process: three algorithms  For n process: Bakery algorithm Assume that the basic machine-language instructions (such as load, store, and test) are executed atomically. Hardware solutions  test-and-set instruction  Swap instruction Semaphore Monitor

32. Silberschatz, Galvin and Gagne  2002 7.32 Operating System Concepts Semaphores The hardware solutions to CS problem presented in previous section are not easy to generalize to more complex problems and are complicated for application programmer. To overcome this difficulty, we can use a synchronization tool called a semaphore. A semaphore S is an integer variable can only be accessed via two indivisible (atomic) operations ： F wait (S) signal (S) while (S  0) ; //no-op S++; S--; When one process modifies S, no other process can simultaneously modify it.

33. Silberschatz, Galvin and Gagne  2002 7.33 Operating System Concepts Semaphore for n-process CS problem Shared data: semaphore mutex; //initially mutex = 1 for mutual exclusion Process P i : do { wait(mutex); CS signal(mutex); RS } while (1); wait (S) signal (S) while (S  0) ; S++; S--; Simple and easy The number of mutex == the number of resources available

34. Silberschatz, Galvin and Gagne  2002 7.34 Operating System Concepts Binary Semaphores Counting semaphore – integer value can range over an unrestricted domain (previous example for semaphore). Binary semaphore – integer value can range only between 0 and 1. It is simpler to implement binary semaphore than counting semaphore.

35. Silberschatz, Galvin and Gagne  2002 7.35 Operating System Concepts Usage of Semaphore Semaphore can be used to solve various synchronization problems. Execute S 2 in P 2 only after executing S 1 in P 1 Semaphore S is initialized to 0 P 1 : P 2 :... … S 1 wait(S) signal(S) S 2…

36. Silberschatz, Galvin and Gagne  2002 7.36 Operating System Concepts Semaphore Implementation The main disadvantage of previous semaphore and other schemes is that they all require busy waitng. Busy waiting wastes CPU cycles that some other process might be able to use productively in multiprogramming system. This type of semaphore is also called a spinlock. The advantage of a spinlock (in multiprocessor system) is that no context switch is require when a process must wait on a lock, and a context switch may take considerable time. Thus, when locks are expected to be held for short times, spinlocks are useful.

37. Silberschatz, Galvin and Gagne  2002 7.37 Operating System Concepts Semaphore without Busy Waiting To overcome the need for busy waiting, we modify the definition of the wait and signal semaphore operations. Define a semaphore as a record typedef struct { int value; struct process *list; } semaphore; Two simple operations: (provided by OS as system calls)  block() ： suspends the process that invokes it.  wakeup(P) ： resumes the execution of a blocked process P.

38. Silberschatz, Galvin and Gagne  2002 7.38 Operating System Concepts Semaphore operations now defined as wait (semaphore *S): S->value--; if (S->value < 0) { add this process to S->list; //add into a queue block(); // switch this process to waiting state } signal(S): S->value++; if (S->value <= 0) { remove a process P from S->L; //remove from a queue wakeup(P); // switch process P to ready state } Semaphore without Busy Waiting

39. Silberschatz, Galvin and Gagne  2002 7.39 Operating System Concepts 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 wait(S); wait(Q); wait(Q); wait(S); … … signal(S); signal(Q); signal(Q) signal(S); P 0 and P 1 might deadlock. Starvation or indefinite blocking ： Processes wait indefinitely within the semaphore. Deadlock-free does not guarantee no starvation.

40. Silberschatz, Galvin and Gagne  2002 7.40 Operating System Concepts Classical Problems of Synchronization Three problems used for testing synchronization schemes Bounded-Buffer Problem (Producer-Consumer Problem) Readers and Writers Problem Dining-Philosophers Problem How to solve these problems by using semaphore? Producer-consumer (bounded-buffer) problem: A pool consists of n buffers (each holds a item) semaphore full, empty, mutex; mutex(1): control of mutual exclusion empty(n), full(0): the number of empty and full buffers

41. Silberschatz, Galvin and Gagne  2002 7.41 Operating System Concepts Bounded-Buffer Problem do { … produce an item in nextp … wait(empty); //wait if empty<=0 wait(mutex); //wait if mutex<=0 … add nextp to buffer //CS … signal(mutex); signal(full); // full++ } while (1); Producer Consumer do { wait(full); //wait if full<=0 wait(mutex); … remove an item from buffer to nextc //CS … signal(mutex); signal(empty); // empty++ … consume the item in nextc … } while (1);

42. Silberschatz, Galvin and Gagne  2002 7.42 Operating System Concepts Readers-Writers Problem A file is to be shared among several concurrent processes. If two or more reader accessed the file simultaneously, it’s OK. However, if a writer and some other process want to access the shared file simultaneously, chaos may ensue. (writer should have exclusive access to the shared file) Assume that no reader will be kept waiting unless a writer has already obtained permission to use the shared file semaphore mutex, wrt; Initially: mutex = 1, //mutual exclusion for reading wrt = 1, //mutual exclusion for reading and writing readcount = 0 // count for reader

43. Silberschatz, Galvin and Gagne  2002 7.43 Operating System Concepts Readers-Writers Problem Writer Process ： wait(wrt); … writing is performed //CS … signal(wrt); Reader Process ： wait(mutex); // exclusion for readers to find readcount readcount++; if (readcount == 1) wait(wrt); // only the first reader will suspend any writer signal(mutex); … reading is performed //CS … wait(mutex); readcount--; if (readcount == 0) signal(wrt); // the last reader will enable any writer signal(mutex): lock for entering read lock for exiting read // other readers can go and readcount can increase

44. Silberschatz, Galvin and Gagne  2002 7.44 Operating System Concepts Dining-Philosophers Problem The table is laid with five single chopsticks When a hungry philosopher has both his chopsticks at the same time, he eats without release his chopsticks. When he is finishing eating, he puts down both chopsticks and starts thinking It is an example of a large class of concurrency-control problems. semaphore chopstick[5]; //1 initially Grab the chopstick by executing a wait operation on the sem.; release his chopsticks by executing the signal on the sem. rice

45. Silberschatz, Galvin and Gagne  2002 7.45 Operating System Concepts Dining-Philosophers Problem do { wait(chopstick[i]) wait(chopstick[(i+1) % 5]) //needs two for eating … eat … signal(chopstick[i]); signal(chopstick[(i+1) % 5]); … think … } while (1); 1. No two neighbors are eating simultaneously 2. All five philosophers grabs his left chopstick simultaneously, then each will be delayed forever (all right chopsticks are used).  Deadlock

46. Silberschatz, Galvin and Gagne  2002 7.46 Operating System Concepts Dining-Philosophers Problem Solution for deadlock ：  Allow at most four philosophers to be sitting simultaneously at the table.  Allow a philosopher to pick up his chopsticks only if both chopsticks are available (pick tem up in CS).  An odd philosopher picks up first his left chopstick and then his right chopstick, whereas an even philosopher picks up his right chopstick and then his left chopstick.  Deadlock-free solution doesn’t means no starvation. One philosopher might starve to death.

47. Silberschatz, Galvin and Gagne  2002 7.47 Operating System Concepts Monitor n Although semaphores provide a convenient and effective mechanism for process synchronization, their incorrect use can still result in timing errors that are difficult to detect (such as signal() comes before wait()). Even an excellent programmer may cause some errors when he uses semaphores to solve CS problem. n To deal with the problem, a high-level synchronization constructs are introduced – monitor.

48. Silberschatz, Galvin and Gagne  2002 7.48 Operating System Concepts Monitors The representation of a monitor type consists of  declarations of variables whose values define the state of an instance of the type  procedures or functions that implement operations on the type Ensure that only one process at a time can be active within the monitor (other processes must wait in queue) Procedure defined within a monitor can access only those variables declared locally within the monitor and its formal parameters

49. Silberschatz, Galvin and Gagne  2002 7.49 Operating System Concepts monitor monitor-name { shared variable declarations procedure body P1 (…) {... } procedure body P2 (…) {... } procedure body Pn (…) {... } { initialization code } Monitors concurrent processes wait in queue

50. Silberschatz, Galvin and Gagne  2002 7.50 Operating System Concepts Monitors To allow a process to wait within the monitor, a condition variable must be declared, as condition x, y; Condition variable can only be used with the operations wait and signal.  The operation x.wait(); means that the process invoking this operation is suspended until another process invokes x.signal();  The x.signal operation resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect.

51. Silberschatz, Galvin and Gagne  2002 7.51 Operating System Concepts Monitor With Condition Variables

52. Silberschatz, Galvin and Gagne  2002 7.52 Operating System Concepts Dining Philosophers Example monitor dp { enum {thinking, hungry, eating} state[5]; condition self[5]; void pickup(int i) // following slides void putdown(int i) // following slides void test(int i) // following slides void init() { for (int i = 0; i < 5; i++) state[i] = thinking; } dp.pickup(i); ….. eat …. dp.putdown(i);

53. Silberschatz, Galvin and Gagne  2002 7.53 Operating System Concepts Dining Philosophers (1/2) void pickup(int i) { state[i] = hungry; test[i]; //check neighbors if (state[i] != eating) self[i].wait(); } void putdown(int i) { state[i] = thinking; // test left and right neighbors test((i+4) % 5); test((i+1) % 5); } void test(int i) { if ( (state[(I + 4) % 5] != eating) && (state[i] == hungry) && (state[(i + 1) % 5] != eating)) { state[i] = eating; self[i].signal(); }

54. Silberschatz, Galvin and Gagne  2002 7.54 Operating System Concepts Dining Philosophers (2/2) P0P0 P1P1 P2P2 P3P3 P4P4 thinking hungry eating thinking hungry eating thinking dp.pickup(1); dp.pickup(2); ….. P 1 eats; dp.putdown(1); …. P 1 wants to eat and pickup(1); state[1]=hungry; test(1); //pass state[1]=eating; self[1].signal; //no effect Now P 2 wants to eat and pickup(2) state[2]=hungry; test[2]; //fail state[1]=eating self[2].wait(); P 1 eats (enter CS); P 1 finishes and putdown(1); state[1]=thinking; test(0); // fail state[0]!=hungry test(2); //pass state[2]=eating; self[2].signal(); // wake up P 2 thinking