2. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-1 Copyright © 2004 Pearson Education, Inc.

3. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-2 Copyright © 2004 Pearson Education, Inc. Basic Synchronization Principles 8

4. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-3 Copyright © 2004 Pearson Education, Inc. Cooperating Processes Multiprogramming created an environment for concurrent processes to execute Concurrent processes executing in the operating system allows for the processes to cooperate with other processes. Processes are cooperating if they can affect each other. The simplest example of how this can happen is where two processes are using the same file. One process may be writing to a file, while another process is reading from the file; so, what is being read may be affected by what is being written. Processes cooperate by sharing data. Cooperation is important for several reasons: –Information sharing, computation speedup, modularity, convinience

5. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-4 Copyright © 2004 Pearson Education, Inc. cooperating processes are processes that cooperate to achieve a specific task. A task is initially broken into subtasks, each subtask is assigned to a process that should pass the result (or input) to another process and so on, until the task is done. Multiple cooperating processes introduce the potential for new synchronization problems in software implementation –Critical section –deadlock

6. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-5 Copyright © 2004 Pearson Education, Inc. Synchronization problems These synchronization problems can occur whenever two or more concurrent processes use any shared resource. How these synchronization problems arise in concurrent applications? Abstract mechanism that can be used to solve synchronization problems.

7. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-6 Copyright © 2004 Pearson Education, Inc. Critical sections A real life example –In automobile transportation, intersections are part of a street, but they are unique part of the street because the intersection is a shared between two different streets. –The traffic intersection is a critical section of these two streets, in the sense that only one vehicle can be in the intersection at a time. –Eithor vehicle can use the critical section, provided that the others is not using it

8. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-7 Copyright © 2004 Pearson Education, Inc. Traffic Intersections Critical section

9. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-8 Copyright © 2004 Pearson Education, Inc. critical sections Critical sections occur in concurrent software whenever two processes access a common shared variable Like bus and car, certain parts of the code are the software critical sections Suppose 2 processes p1 & p2, execute concurrently to access a common integer varibale balance

10. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-9 Copyright © 2004 Pearson Education, Inc. Critical Sections shared double balance; Code for p 1 Code for p 2...... balance = balance + amount;balance = balance - amount;... balance+=amountbalance-=amount balance

11. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-10 Copyright © 2004 Pearson Education, Inc. Compiled instructions code schema for p1 load R1, balance load R2, amount add R1, R2 store R1, balance code schema for p2 load R1, balance load R2, amount sub R1, R2 store R1, balance

12. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-11 Copyright © 2004 Pearson Education, Inc. Critical Sections (2) … load R1, balance load R2, amount … load R1, balance load R2, amount sub R1, R2 store R1, balance … add R1, R2 store R1, balance … Timer interrupt Execution of p 1 Execution of p 2

13. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-12 Copyright © 2004 Pearson Education, Inc. Critical Sections Mutual exclusion: Only one process can be in the critical section at a time There is a race to execute critical sections The sections may be defined by different code in different processes Without mutual exclusion, results of multiple execution are not determinate Need an OS mechanism so programmer can resolve races

14. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-13 Copyright © 2004 Pearson Education, Inc. Race condition The programs defining p1 & p2 have a critical section with respect to their use of the shared variable balance For p1 critical section is the computing the sum of balance and amount. But for p2 it is for computing the difference of balance and amount We say that there is a race condition between p1 and p2, because the outcome of the computation depends on the relative times that the two processes execute their respective critical sections

15. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-14 Copyright © 2004 Pearson Education, Inc. Some Possible Solutions Disable interrupts Software solution – locks Enter(), exit() method … something new …

16. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-15 Copyright © 2004 Pearson Education, Inc. Disabling Interrupts Sample code: shared double balance; Code for p 1 Code for p 2disableInterrupts(); balance = balance + amount;balance = balance - amount;enableInterrupts(); Interrupts could be disabled arbitrarily long Really only want to prevent p 1 and p 2 from interfering with one another; this blocks all p i Try using a shared “lock” variable

17. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-16 Copyright © 2004 Pearson Education, Inc. Using a Lock Variable shared boolean lock = FALSE; shared double balance; Code for p 1 Code for p 2/* Acquire the lock */ while(lock) ; lock = TRUE;/* Execute critical sect */ balance = balance + amount; balance = balance - amount;/* Release lock */ lock = FALSE; lock = FALSE;

18. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-17 Copyright © 2004 Pearson Education, Inc. Busy Wait Condition p1p1 p2p2 Blocked at while lock = TRUE lock = FALSE Interrupt

19. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-18 Copyright © 2004 Pearson Education, Inc. Unsafe “Solution” shared boolean lock = FALSE; shared double balance; Code for p 1 Code for p 2/* Acquire the lock */ while(lock) ; lock = TRUE;/* Execute critical sect */ balance = balance + amount; balance = balance - amount;/* Release lock */ lock = FALSE; Worse yet … another race condition … Is it possible to solve the problem?

20. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-19 Copyright © 2004 Pearson Education, Inc. Atomic Lock Manipulation enter(lock) {exit(lock) { disableInterrupts(); /* Loop until lock is TRUE */ lock = FALSE; while(lock) { enableInterrupts(); /* Let interrupts occur */} enableInterrupts(); disableInterrupts(); } lock = TRUE; enableInterrupts(); } Bound the amount of time that interrupts are disabled Can include other code to check that it is OK to assign a lock … but this is still overkill …

21. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-20 Copyright © 2004 Pearson Education, Inc. A Semaphore

22. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-21 Copyright © 2004 Pearson Education, Inc. Dijkstra Semaphore Invented in the 1960s Conceptual OS mechanism, with no specific implementation defined (could be enter() / exit() ) Basis of all contemporary OS synchronization mechanisms Train story

23. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-22 Copyright © 2004 Pearson Education, Inc. Notation Proc_0() {proc_1() { while(TRUE) { while(TRUE { <compute section>; <critical section>; }} fork(proc_0, 0); fork(proc_1, 0);

24. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-23 Copyright © 2004 Pearson Education, Inc. Solving the Canonical Problem Proc_0() {proc_1() { while(TRUE) { while(TRUE { <compute section>; P(mutex); P(mutex); <critical section>; V(mutex); V(mutex); }} semaphore mutex = 1; fork(proc_0, 0); fork(proc_1, 0);

25. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-24 Copyright © 2004 Pearson Education, Inc. Shared Account Balance Problem Proc_0() {proc_1() {.../* Enter the CS */ P(mutex); P(mutex); balance += amount; balance -= amount; V(mutex); V(mutex);...} semaphore mutex = 1; fork(proc_0, 0); fork(proc_1, 0);

26. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-25 Copyright © 2004 Pearson Education, Inc. Sharing Two Variables (signaling) proc_A() { while(TRUE) { ; update(x); /* Signal proc_B */ V(s1); ; /* Wait for proc_B */ P(s2); retrieve(y); } semaphore s1 = 0; semaphore s2 = 0; fork(proc_A, 0); fork(proc_B, 0); proc_B() { while(TRUE) { /* Wait for proc_A */ P(s1); retrieve(x); ; update(y); /* Signal proc_A */ V(s2); ; }

27. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-26 Copyright © 2004 Pearson Education, Inc. Device Controller Synchronization The semaphore principle is logically used with the busy and done flags in a controller Driver signals controller with a V(busy), then waits for completion with P(done) Controller waits for work with P(busy), then announces completion with V(done)

28. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-27 Copyright © 2004 Pearson Education, Inc. Classical synchronization problems Bounded buffer (producer consumer problem) Reader writer problem Dining philosopher problem Cigarette smoker problem Sleeping barber problem

29. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-28 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 9 The Dining Philosophers

30. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-29 Copyright © 2004 Pearson Education, Inc. Dining Philosophers while(TRUE) { think(); eat(); } Philosophers Think and Ignore Food When They Want to Eat, Need Two Forks Pick Up One and Then Another How Do We Prevent Two Philosophers Holding Same Fork at Same Time? What is a Synchronization Scheme for the Problem?

31. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-30 Copyright © 2004 Pearson Education, Inc. Dining Philosophers Is Semaphore Solution Correct? philosopher(int i) { while(TRUE) { // Think // Eat P(fork[i]); P(fork[(i+1) mod 5]); eat(); V(fork[(i+1) mod 5]); V(fork[i]); } 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);

32. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-31 Copyright © 2004 Pearson Education, Inc. Dining Philosophers A Correct Semaphore Solution philosopher(int i) { while(TRUE) { // Think // 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);

33. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-32 Copyright © 2004 Pearson Education, Inc. AND Synchronization Suppose Multiple Processes Need Access to Two Resources, R 1 and R 2 –Some Processes Access R 1 –Some Processes Access R 2, –Some Processes Need Both How are Resources and Process Requests Ordered to Insure Deadlock Avoidance? Define a Simultaneous P Able to Access All Semaphores at Same Time P simultaneous (S 1, …, S n )

34. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-33 Copyright © 2004 Pearson Education, Inc. AND Synchronization Example P.sim(int S, int R) { P(mutex); S--; R--; if((S < 0) || (R < 0)) { V(mutex); P(block); } else V(mutex); } V.sim(int S, int R) { P(mutex); S++; R++; if(((S >= 0) && (R >= 0)) && ((S == 0) || (R == 0))) V(block); V(mutex); } semaphore mutex = 1; semaphore block = 0;

35. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-34 Copyright © 2004 Pearson Education, Inc. The bounded buffer (Producer Consumer Problem) System incorporates two single threaded processes –One of which produces information(producer) –Another that uses information (consumer) Two processes communicate by having the producer obtain an empty buffer pool, fill it with information and place it in a pool of full buffers.

36. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-35 Copyright © 2004 Pearson Education, Inc. Bounded Buffer Problem Producer Consumer Empty Pool Full Pool

37. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-36 Copyright © 2004 Pearson Education, Inc. Bounded Buffer Problem producer() { buf_type *next, *here; while(TRUE) { produce_item(next); /* Claim an empty */ P(empty); P(mutex); here = obtain(empty); V(mutex); copy_buffer(next, here); P(mutex); release(here, fullPool); V(mutex); /* Signal a full buffer */ V(full); } semaphore mutex = 1; semaphore full = 0; /* A general (counting) semaphore */ semaphore empty = N; /* A general (counting) semaphore */ buf_type buffer[N]; fork(producer, 0); fork(consumer, 0); consumer() { buf_type *next, *here; while(TRUE) { /* Claim full buffer */ P(mutex); P(full); here = obtain(full); V(mutex); copy_buffer(here, next); P(mutex); release(here, emptyPool); V(mutex); /* Signal an empty buffer */ V(empty); consume_item(next); }

38. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-37 Copyright © 2004 Pearson Education, Inc. Solution uses 3 semaphores. –Mutex is a binary semaphore –Full and empty are counting semaphores Mutex semaphore protects the critical section related adding/deleting buffers to/from a pool. The two other semaphores are used by the producer/consumer process to tell the other process that there are full/empty buffers available.

39. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-38 Copyright © 2004 Pearson Education, Inc. Readers-writers problem Here a resource is to be shared among a community of processes of distinct types : Readers and Writers, –A reader process can share the resource with any other reader process, but not with any writer process –A writer process requires exclusive access to the resource whenever it acquires any access to the resource  Eg: a file is to be shared among a set of processes

40. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-39 Copyright © 2004 Pearson Education, Inc. Readers-Writers Problem Readers Writers

41. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-40 Copyright © 2004 Pearson Education, Inc. Readers-Writers Problem (2) Reader Shared Resource Reader Writer

42. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-41 Copyright © 2004 Pearson Education, Inc. Readers-Writers Problem (3) Reader Shared Resource Reader Writer

43. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-42 Copyright © 2004 Pearson Education, Inc. Readers-Writers Problem (4) Reader Shared Resource Reader Writer

44. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-43 Copyright © 2004 Pearson Education, Inc. First Solution As long as the reader holds the resource and there are new readers arriving, any writer must wait for the resource become available. –The first reader accessing the shared resource must compete with any writers, but once a reader succeeds, other readers can pass directly into the critical section, provided that at least one reader is in the critical section –Readers keep the count of the no. of readers in the critical section, with the readcount variable which is updated and tested inside its own critical section

45. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-44 Copyright © 2004 Pearson Education, Inc. First Solution reader() { while(TRUE) { ; P(mutex); readCount++; if(readCount == 1) P(writeBlock); V(mutex); /* Critical section */ access(resource); P(mutex); readCount--; if(readCount == 0) V(writeBlock); V(mutex); } resourceType *resource; int readCount = 0; semaphore mutex = 1; semaphore writeBlock = 1; fork(reader, 0); fork(writer, 0); writer() { while(TRUE) { ; P(writeBlock); /* Critical section */ access(resource); V(writeBlock); } First reader competes with writers Last reader signals writers

46. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-45 Copyright © 2004 Pearson Education, Inc. First Solution (2) reader() { while(TRUE) { ; P(mutex); readCount++; if(readCount == 1) P(writeBlock); V(mutex); /* Critical section */ access(resource); P(mutex); readCount--; if(readCount == 0) V(writeBlock); V(mutex); } resourceType *resource; int readCount = 0; semaphore mutex = 1; semaphore writeBlock = 1; fork(reader, 0); fork(writer, 0); writer() { while(TRUE) { ; P(writeBlock); /* Critical section */ access(resource); V(writeBlock); } First reader competes with writers Last reader signals writers Any writer must wait for all readers Readers can starve writers “Updates” can be delayed forever May not be what we want

47. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-46 Copyright © 2004 Pearson Education, Inc. Writer Precedence reader() { while(TRUE) { ; P(writePending); P(readBlock); P(mutex1); readCount++; if(readCount == 1) P(writeBlock); V(mutex1); V(readBlock); V(writePending); access(resource); P(mutex1); readCount--; if(readCount == 0) V(writeBlock); V(mutex1); } int readCount = 0, writeCount = 0; semaphore mutex = 1, mutex2 = 1; semaphore readBlock = 1, writeBlock = 1, writePending = 1; fork(reader, 0); fork(writer, 0); writer() { while(TRUE) { ; P(mutex2); writeCount++; if(writeCount == 1) P(readBlock); V(mutex2); P(writeBlock); access(resource); V(writeBlock); P(mutex2) writeCount--; if(writeCount == 0) V(readBlock); V(mutex2); } 1234

48. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-47 Copyright © 2004 Pearson Education, Inc. The Sleepy Barber Waiting Room Entrance to Waiting Room (sliding door) Entrance to Barber’s Room (sliding door) Shop Exit Barber can cut one person’s hair at a time Other customers wait in a waiting room

49. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-48 Copyright © 2004 Pearson Education, Inc. Sleeping barber problem The analogy is based upon a hypothetical barber shop with one barber. The barber has one barber chair and a waiting room with a number of chairs in it. When the barber finishes cutting a customer's hair, he dismisses the customer and then goes to the waiting room to see if there are other customers waiting. If there are, he brings one of them back to the chair and cuts his hair. If there are no other customers waiting, he returns to his chair and sleeps in it. Each customer, when he arrives, looks to see what the barber is doing. If the barber is sleeping, then the customer wakes him up and sits in the chair. If the barber is cutting hair, then the customer goes to the waiting room. If there is a free chair in the waiting room, the customer sits in it and waits his turn. If there is no free chair, then the customer leaves. Based on a naïve analysis, the above description should ensure that the shop functions correctly, with the barber cutting the hair of anyone who arrives until there are no more customers, and then sleeping until the next customer arrives.

50. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-49 Copyright © 2004 Pearson Education, Inc. Sleepy barber – problems The problems are all related to the fact that the actions by both the barber and the customer (checking the waiting room, entering the shop, taking a waiting room chair, etc.) all take an unknown amount of time. In one example, A customer may arrive and observe that the barber is cutting hair, so he goes to the waiting room. While he is on his way, the barber finishes the haircut he is doing and goes to check the waiting room. Since there is no one there (the customer not having arrived yet), he goes back to his chair and sleeps. The barber is now waiting for a customer and the customer is waiting for the barber. In another example, two customers may arrive at the same time when there happens to be a single seat in the waiting room. They observe that the barber is cutting hair, go to the waiting room, and both attempt to occupy the single chair

51. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-50 Copyright © 2004 Pearson Education, Inc. Sleepy Barber (aka Bounded Buffer) customer() { while(TRUE) { customer = nextCustomer(); if(emptyChairs == 0) continue; P(chair); P(mutex); emptyChairs--; takeChair(customer); V(mutex); V(waitingCustomer); } semaphore mutex = 1, chair = N, waitingCustomer = 0; int emptyChairs = N; fork(customer, 0); fork(barber, 0); barber() { while(TRUE) { P(waitingCustomer); P(mutex); emptyChairs++; takeCustomer(); V(mutex); V(chair); }

52. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-51 Copyright © 2004 Pearson Education, Inc. Cigarette smoker’s problem Assume a cigarette requires three ingredients to smoke: Tobacco, Smoking Paper, A Match Assume there are also three chain smokers around a table, each of whom has an infinite supply of one of the three ingredients — one smoker has an infinite supply of tobacco, another has an infinite supply of paper, and the third has an infinite supply of matches. Assume there is also a non-smoking arbiter. The arbiter enables the smokers to make their cigarettes by arbitrarily (non deterministically) selecting two of the smokers, taking one item out of each of their supplies, and placing the items on the table. The arbiter then notifies the third smoker that they have done this. The third smoker removes the two items from the table and uses them (along with their own supply) to make a cigarette, which they smoke for a while. Meanwhile, the arbiter, seeing the table empty, again chooses two smokers at random and places their items on the table. This process continues forever.

53. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-52 Copyright © 2004 Pearson Education, Inc. The smokers do not hoard items from the table; a smoker only begins to roll a new cigarette once they have finished smoking the last one. For instance if the arbiter places tobacco and paper on the table while the match-supply smoker is smoking, the tobacco and paper will remain untouched on the table until the match-supply smoker is finished with their cigarette and then collects the items

54. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-53 Copyright © 2004 Pearson Education, Inc. Cigarette Smoker’s Problem Three smokers (processes) Each wish to use tobacco, papers, & matches –Only need the three resources periodically –Must have all at once 3 processes sharing 3 resources –Solvable, but difficult

55. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-54 Copyright © 2004 Pearson Education, Inc. Agent process 1 do forever { 2 P( lock ); 3 randNum = rand( 1, 3 ); // Pick a random number from 1-3 4 if ( randNum == 1 ) { 5 // Put tobacco on table 6 // Put paper on table 7 V( smoker_match ); // Wake up smoker with match 8 } else if ( randNum == 2 ) { 9 // Put tobacco on table 10 // Put match on table 11 V( smoker_paper ); // Wake up smoker with paper 12 } else { 13 // Put match on table 14 // Put paper on table 15 V( smoker_tobacco ); } // Wake up smoker with tobacco 16 V( lock ); 17 P( agent ); // Agent sleeps 18 } // end forever loop

56. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-55 Copyright © 2004 Pearson Education, Inc. Smoker process 1 do forever { 2 P( smoker_tobacco ); // Sleep right away 3 P( lock ); 4 // Pick up match 5 // Pick up paper 6 V( agent ); 7 V( lock ); 8 // Smoke (but don't inhale). 9 }

57. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-56 Copyright © 2004 Pearson Education, Inc. Implementing Semaphores Minimize effect on the I/O system Processes are only blocked on their own critical sections (not critical sections that they should not care about) If disabling interrupts, be sure to bound the time they are disabled

58. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-57 Copyright © 2004 Pearson Education, Inc. Implementing Semaphores: class semaphore { int value; public: semaphore(int v = 1) { value = v;}; P(){ disableInterrupts(); while(value == 0) { enableInterrupts(); disableInterrupts(); } value--; enableInterrupts(); }; V(){ disableInterrupts(); value++; enableInterrupts(); };

59. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-58 Copyright © 2004 Pearson Education, Inc. Implementing Semaphores: Test and Set Instruction FALSE m Primary Memory … R3 … Data Register CC Register (a)Before Executing TS TRUE m Primary Memory FALSE R3 =0 Data Register CC Register (b) After Executing TS “TS R3, m “ loads register R3 tests its value and writes a TRUE back to location m. OS function - TS(m): [Reg_i = memory[m]; memory[m] = TRUE;]

60. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-59 Copyright © 2004 Pearson Education, Inc. Using the TS Instruction boolean s = FALSE;... while(TS(s)) ; s = FALSE;... semaphore s = 1;... P(s) ; V(s);...

61. Operating Systems: A Modern Perspective, Chapter 8 Slide 8-60 Copyright © 2004 Pearson Education, Inc. Implementing the General Semaphore struct semaphore { int value = ; boolean mutex = FALSE; boolean hold = TRUE; }; shared struct semaphore s; P(struct semaphore s) { while(TS(s.mutex)) ; s.value--; if(s.value < 0) ( s.mutex = FALSE; while(TS(s.hold)) ; } else s.mutex = FALSE; } V(struct semaphore s) { while(TS(s.mutex)) ; s.value++; if(s.value <= 0) ( while(!s.hold) ; s.hold = FALSE; } s.mutex = FALSE; }