1 / 66

Chapter 7: Process Synchronization

Chapter 7: Process Synchronization. Background The Critical-Section Problem Synchronization Hardware Semaphores Classical Problems of Synchronization Critical Regions Monitors Synchronization in Solaris 2 & Windows 2000. Background.

gisela
Download Presentation

Chapter 7: Process Synchronization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 7: Process Synchronization • Background • The Critical-Section Problem • Synchronization Hardware • Semaphores • Classical Problems of Synchronization • Critical Regions • Monitors • Synchronization in Solaris 2 & Windows 2000

  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. • Shared-memory solution to bounded-butter problem (Chapter 4) allows at most n – 1 items in buffer at the same time. 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 a new item is added to the buffer

  3. Bounded-Buffer • Shared data #define BUFFER_SIZE 10 typedef struct { . . . } item; item buffer[BUFFER_SIZE]; int in = 0; int out = 0; int counter = 0;

  4. Bounded-Buffer • Producer process item nextProduced; while (1) { while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = nextProduced; in = (in + 1) % BUFFER_SIZE; counter++; }

  5. Bounded-Buffer • Consumer process item nextConsumed; while (1) { while (counter == 0) ; /* do nothing */ nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; }

  6. Bounded Buffer • The statementscounter++;counter--;must be performed atomically. • Atomic operation means an operation that completes in its entirety without interruption.

  7. Bounded Buffer Analysis • Although “P” and “C” routines are logically correct in themselves, they may not work correctly running concurrently. • The counter variable is shared between the two processes • When ++counter and --count are done concurrently, the results are unpredictable because the operations are not atomic • Assume ++counter, --counter compiles as follows: • ++counter --counterregister1 = counter register2 = counter register1 = register1 + 1 register2 = register2 - 1 counter = register1 counter = register2

  8. Bounded Buffer Analysis • 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. • P and C get unpredictable access to CPU due to time slicing

  9. Bounded Buffer Analysis • Assume counter is initially 5. One interleaving of statements is:producer: register1 = counter (register1 = 5)producer: register1 = register1 + 1 (register1 = 6)consumer: register2 = counter (register2 = 5)consumer: register2 = register2 – 1 (register2 = 4)producer: counter = register1 (counter = 6)consumer: counter = register2 (counter = 4) • The value of count may be either 4 or 6, where the correct result should be 5.We have a “race condition” here.

  10. Race Condition • Race condition: The situation where several processes access – and manipulate shared data concurrently. The final value of the shared data depends upon which process finishes last. • To prevent race conditions, concurrent processes must be synchronized. • Is there any logical difference in a race condition if the two “racing” processes are on two distinct CPU’s in an SMP environment vs. both running concurrently on a single uniprocessor? … is one worse than the other?

  11. The Critical-Section Problem • n processes all competing to use some shared data • Each process has a code segment, called critical section, in which the shared data is accessed. • Problem – ensure that when one process is executing in its critical section, no other process is allowed to execute in its critical section.

  12. Solution to Critical-Section Problem 1. Mutual Exclusion. If process Pi is executing in its critical section, then no other processes can be executing in their critical sections – unless it is by deliberate design by the programmer – see readers/writer problem later. 2. *Progress. If there exist some processes that wish to enter their critical section, then processes outside of their critical sections cannot participate in the decision of which one will enter its CS next, and this selection cannot be postponed indefinitely.In other words: No process running outside its CS may block other processes from entering their CS’s – ie., a process must be in a CS to have this privilege. 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 - no starvation. • Assume that each process executes at a nonzero speed • No assumption concerning relative speed of the n processes.* Item 2 is A modification of the rendition given in Silberschatz which appears to be “muddled” – see “Modern Operating Systems”, 1992, by Tanenbaum, p. 35.See next slide ffrom other author’s rendition of these conditions for clarification:

  13. Solution to Critical-Section Problem From:“Operating systems”, by William Stallings, 4th ed., page 207 • Mutual exclusion must be enforced: Only one process at a time is allowed into the critical section (CS) • A process that halts in its noncritical section must do so without interfering with other processes • It must not be possible for a process requiring access to a CS to be delayed indefinitely: no deadlock or starvation. • When no process is in a critical section, any process that requests entry to its CS must be permitted to enter without delay. • No assumptions are made about relative process speeds or number of processors. • A process remains inside its CS for a finite time only.Also From “Modern Operating Systems”, 1992, by Tanenbaum, p. 35.- No two processes may be simultaneously inside their critical sections.- No assumptions may be made about speeds or the numbers of CPUs- No process running outside its CS may block other processes from entering their CS’s - No process should have to wait forever to enter its CS

  14. Initial Attempts to Solve Problem • Only 2 processes, P0 and P1 • General structure of process Pi(other process Pj) do { entry section critical section exit section reminder section } while (1); • Processes may share some common variables to synchronize their actions.

  15. Algorithm 1 • Assume two processes: P0 and P1 • Shared variables: • int turn;initially turn = 0 /* let P0 have turn first */ • if (turn == i) Pi can enter its critical section, i = 0, 1 • For process Pi : // where the “other” process is Pj do { while (turn != i) ; // wait while it is your turn critical section turn = j; // allow the “other” to enter after exiting CS reminder section } while (1); • Satisfies mutual exclusion, but not progress • if Pj decides not to re-enter or crashes outside CS, then Pi cannot ever get in • A process cannot make consecutive entries to CS even if “other” is not in CS - other prevents a proc from entering while not in CS - a “no-no”

  16. Algorithm 2 • Shared variables • boolean flag[2]; // “interest” bitsinitially flag [0] = flag [1] = false. • flag [i] = true Pideclaresinterest in entering its critical section • Process Pi // where the “other” process is Pj do { flag[i] = true; // declare your own interest while (flag[ j]) ; //wait if the other guy is interested critical section flag [i] = false; // declare that you lost interest remainder section // allows other guy to enter } while (1); • Satisfies mutual exclusion, but not progress requirement. • If flag[ I] == flag[ j] == true, then deadlock - no progress • but barring this event, a non-CS guy cannot block you from entering • Can make consecutive re-entries to CS if other not interested • Uses “mutual courtesy”

  17. Algorithm 3 • Peterson’s solution • Combined shared variables & approaches of algorithms 1 and 2. • Process Pi// where the “other” process is Pj do { flag [i] = true; // declare your interest to enter turn = j; // assume it is the other’s turn-give PJ a chance while (flag [ j ] and turn == j) ; critical section flag [i] = false; remainder section } while (1); • Meets all three requirements; solves the critical-section problem for two processes (the best of all worlds - almost!). • Turn variable breaks any deadlock possibility of previous example,AND prevents “hogging” – Pi setting turn to j gives PJ a chance after each pass of Pi’s CS • Flag[ ] variable prevents getting locked out if other guy never re-enters or crashes outside and allows CS consecutive access other not intersted in entering. • Down side is that waits are spin loops. • Question: what if the setting flag[i], or turn is not atomic?

  18. Bakery Algorithm… or the Supermarket deli algorithm • Before entering its critical section, process receives a number. Holder of the smallest number enters the critical section. • If processes Pi and Pj receive the same number, if i < j, then Pi is served first; else Pj is served first. • The numbering scheme always generates numbers in increasing order of enumeration; i.e., 1,2,3,3,3,3,4,5... Critical section for n processes

  19. Bakery Algorithm • Notation < lexicographical order (ticket #, process id #) • (a,b) < c,d) if a < c or if a = c and b < d • max (a0,…, an-1) is a number, k, such that k ai for i = 0, … , n – 1 • Shared data boolean choosing[n]; int number[n]; Data structures are initialized to false and 0 respectively

  20. Bakery Algorithm For Process Pi do { /* Has four states: choosing, scanning, CS, remainder section */ choosing[i] = true; //process does not “compete” while choosing a # number[i] = max(number[0], number[1], …, number [n – 1]) + 1; choosing[i] = false; /*scan all processes to see if if Pi has lowest number: */ for (k = 0; k < n; k++) { /* check process k, book uses dummy variable “j” */ while (choosing[ k ]); /*ifPk is choosing a number wait till done */ while ((number[k] != 0) && (number[k], k < number[ i ], i)) ; /* if (Pk is waiting (or in CS) and Pk is “ahead” of Pi then Pi waits */ /*if Pk is not in CS and is not waiting, OR Pk is waiting with a larger number, then skip over Pk - when Pi gets to end of scan, it will have lowest number and will fall thru to the CS */ /* If Pi is waiting on Pk, then number[k] will go to 0 because Pk will eventually get served – thus causing Pi to break out of the while loop and check out the status of the next process if any */ /* the while loop skips over the case k == i */ } critical section number[i] = 0; /* no longer a candidate for CS entry */ remainder section } while (1);

  21. Synchronization HardwareTest and Set • targer is the lock: target ==1 means cs locked, else open • Test and modify the content of a word atomically. boolean TestAndSet(boolean target) { boolean rv = target; target = true; return rv; // return the original value of target } • See “alternate definition” in “Principles of Concurrency” notes • if target ==1 (locked), target stays 1 and return 1, “wait” • if target ==0 (unlocked), set target to 1(lock door), return 0, and enter “enter CS”

  22. Mutual Exclusion with Test-and-Set • Shared data: boolean lock = false; // if lock == 0, door open, if lock == 1, door locked • Process Pi do { while (TestAndSet(lock)) ; critical section lock = false; remainder section } • See Flow chart (“Alternate Definition” ) in Instructors notes: “Concurrency and Mutual exclusion”, Hardware Supportfor details on how this works.

  23. Synchronization Hardwareswap • Atomically swap two variables.void Swap(boolean &a, boolean &b) { boolean temp = a; a = b; b = temp; }

  24. Mutual Exclusion with Swap for process Pi • Shared data (initialized to false): boolean lock = false; /* shared variable - global */ // if lock == 0, door open, if lock == 1, door locked • Private data boolean key_i = true; • Process Pi do { key_i = true; /* not needed if swap used after CS exit */ while (key_i == true) Swap(lock, key_i ); critical section /* rememberkey_i is now false */ lock = false; /* can also use: swap(lock, key_i ); */ remainder section } • See Flow chart (“Alternate Definition” ) in Instructors notes: “Concurrency and Mutual exclusion”, Hardware Supportfor details on how this works.NOTE: The above applications for mutual exclusion using both test and set and swap do not satisfy bounded waiting requirement - see book pp.199-200 for resolution..

  25. Semaphores • Synchronization tool that does not require busy waiting. • Semaphore S – integer variable • can only be accessed via two indivisible (atomic) operations wait (S): while S 0 do no-op; S--; signal (S): S++;Note: Test before decrement Normally never negative No queue is used (see later) What if more than 1 process is waiting on S and a signal occurs? Employs a spin loop (see later)

  26. Critical Section of n Processes • Shared data: semaphore mutex; //initially mutex = 1 • Process Pi: do { wait(mutex);critical section signal(mutex); remainder section} while (1);

  27. Semaphore Implementation • Get rid of the spin loop, add a queue, and increase functionality (counting semaphore) • Used in UNIX • Define a semaphore as a record typedef struct { int value; struct process *L; } semaphore; • Assume two simple operations: • Block(P) suspends (blocks) the process P. • wakeup(P) resumes the execution of a blocked process P. • Must be atomic

  28. Implementation- as in UNIX • Semaphore operations called by process P now defined as wait(S): S.value--; //Note: decrement before test if (S.value < 0) { add this process to S.L; block(P); //block the process calling wait(S) }// “door” is locked if S.value <= 0;signal(S): S.value++; if (S.value <= 0) { // necessary condition for non-empty queue remove a process P from S.L; wakeup(P); //move P to ready queue } /* use some algorithm for choosing a process to remove from queue, ex: FIFO */

  29. Implementation- continued • Compare to original “classical” definition: • Allows for negative values (“counting” semaphore) • Absolute value of negative value is number of processes waiting in the semaphore • Positive value is the number of processes that can call wait and not block • Wait() blocks on negative • Wait() decrements before testing • Remember: signal moves a process to the ready queue, and not necessarily to immediate execution • How is something this complex made atomic? • Most common: disable interrupts • Use some SW techniques such as Peterson’s solution inside wait and signal – spin-loops would be very short (wait/signal calls are brief) – see p. 204 … different than the spin-loops in classical definition!

  30. Implementation- continued • The counting semaphore has two fundamental applications: • Mutual exclusion for solving the “CS” problem • Controlling access to resources with limited availability,for example in the bounded buffer problem: • block consumer if the buffer empty • block the producer if the buffer is full. • Both applications are used for the bounded buffer problem

  31. Semaphore as a General Synchronization Tool • Execute B in Pj only after A executed in PiSerialize these events (guarantee determinism): • Use semaphore flag initialized to 0 • Code: Pi Pj   Await(flag) signal(flag) B

  32. Deadlock and Starvation • Just because semaphores can solve the “CS” problem, they still can be misused and cause deadlock or 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 P0P1 (1)wait(S); (2)wait(Q); (3) wait(Q); (4)wait(S);   signal(S); signal(Q); signal(Q) signal(S); Random sequence 1, 2, 3, 4 causes deadlock But sequence 1, 3, 2, 4 will not deadlock • Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended.Can be avoided by using FIFO queue discipline.

  33. Two Types of Semaphores • Counting semaphore – integer value can range over an unrestricted domain. • Binary semaphore – integer value can range only between 0 and 1; can be simpler to implement. • Can implement a counting semaphore S as a binary semaphore.

  34. Binary Semaphore Definition Struct b-semaphore { int value; /* boolean, only 0 or 1 allowed */ struct process queue; } Void wait-b (b-semaphore s) { /* see alternate def. Below */ if (s.value == 1) s.value = 0; // Lock the “door” & let process enter CS else { place this process in s.queue and block it;} // no indication of size of queue ... compare to general semaphore } // wait unconditionally leaves b-semaphore value at 0 Void signal-b(b-semaphore s) { //s.value==0 is necessarybut not sufficient if (s.queue is empty) s.value = 1; // condition for empty queue else move a process from s.queue to ready list; } // if only 1 proc in queue, leave value at 0, “moved” proc will go to CS ********************************************************************* Alternate definition of wait-b (simpler): Void wait-b (b-semaphore s) { if (s.value == 0) {place this process in s.queue and block it;} s.value =0; // value was 1, set to 0 } // compare to test & set

  35. Implementing Counting SemaphoreSusing Binary Semaphores • Data structures: binary-semaphore S1, S2; int C: • Initialization: S1 = 1 S2 = 0 C = initial value of semaphore S

  36. Implementing Counting SemaphoreSusing Binary Semaphores (continued) • wait operation wait(S1); C--; if (C < 0) { signal(S1); wait(S2); } else? signal(S1); • signal operation wait(S1); //should this be a “different” S1? C ++; if (C <= 0) signal(S2); else // else should be removed? signal(S1); See a typical example of semaphore operation given in “Chapter 7 notes by Guydosh” posted along with these notes.

  37. Classical Problems of Synchronization • Bounded-Buffer Problem • Readers and Writers Problem • Dining-Philosophers Problem

  38. Bounded-Buffer Problem • Uses both aspects of a counting semaphore: • Mutual exclusion: the mutex semaphore • Limited resource control: full and empty semaphores • Shared data:semaphore full, empty, mutex;where:- full represents the number of “full” (used) slots in the buffer- empty represents the number if “empty” (unused) slots in the buffer- mutex is used for mutual exclusion in the CSInitially:full = 0, empty = n, mutex = 1 /* buffer empty, “door” is open */

  39. Bounded-Buffer Problem Producer Process do { … produce an item in nextp … wait(empty); wait(mutex); … add nextp to buffer … signal(mutex); signal(full); } while (1); Question: what may happen if the mutex wait/signal calls were done before and after the corresponding calls for empty and full respectively?

  40. Bounded-Buffer Problem Consumer Process do { wait(full) wait(mutex); … remove an item from buffer to nextc … signal(mutex); signal(empty); … consume the item in nextc … } while (1); Same Question: what may happen if the mutex wait/signal calls were done before and after the corresponding calls for empty and full respectively? See the trace of a bounded buffer scenario given in “Chapter 7 notes by Guydosh” posted along with these notes.

  41. Readers-Writers Problem • Semaphores used purely for mutual exclusion • No limits on writing or reading the buffer • Uses a single writer, and multiple readers • Multiple readers allowed in CS • Readers have priority over writers for these slides. • As long as there is a reader(s) in the CS, no writer may enter – CS must be empty for a writer to get in • An alternate (more fair approach) is: even if readers are in the CS, no more readers will be allowed in if a writer “declares an interest” to get into the CS – this is the writer preferred approach. It is discussed in more detail in Guydosh’s notes: “Readers-Writers problems Scenario” on the website. • Shared datasemaphore mutex, wrt;Initiallymutex = 1, wrt = 1, readcount = 0 /* all “doors” open, no readers in */

  42. Readers-Writers Problem Writer Process wait(wrt); … writing is performed … signal(wrt);

  43. Readers-Writers Problem Reader Process wait(mutex); // 2nd, 3rd, … readers queues on mutex if 1st reader // waiting for a writer to leave (blocked on wrt). // also guards the modification of readcount readcount++; if (readcount == 1) wait(wrt); //1st reader blocks if any writers in CS signal(mutex); //1st reader is in- open the “floodgates” for its companions … reading is performed … wait(mutex); // guards the modification of readcount readcount--; if (readcount == 0) signal(wrt); // last reader out lets any queued writers in signal(mutex): • See Guydosh’s notes: “Readers-Writers problems Scenario” (website) for a detailed trace of this algorithm.

  44. Dining-Philosophers Problem • Shared data semaphore chopstick[5]; Initially all values are 1 Chopstick i+1 Process i Chopstick i

  45. Dining-Philosophers Problem • Philosopher i: do { wait(chopstick[i]) // left chopstick wait(chopstick[(i+1) % 5]) // right chopstick … eat … signal(chopstick[i]); signal(chopstick[(i+1) % 5]); … think … } while (1); • This scheme guarantees mutual exclusion but has deadlock – what if all 5 philosophers get hungry simultaneously and all grab for the left chopstick at the same time? .. See Monitor implementation for deadlock free solution … sect 7.7

  46. Critical Regions - omit • High-level synchronization construct • A shared variable v of type T, is declared as: v:sharedT • Variable v accessed only inside statement regionvwhenBdoSwhere B is a boolean expression. • While statement S is being executed, no other process can access variable v.

  47. Critical Regions - omit • Regions referring to the same shared variable exclude each other in time. • When a process tries to execute the region statement, the Boolean expression B is evaluated. If B is true, statement S is executed. If it is false, the process is delayed until B becomes true and no other process is in the region associated with v.

  48. Critical Regions Example – Bounded Buffer - omit • Shared data: struct buffer { int pool[n]; int count, in, out; }

  49. Critical Regions Bounded Buffer Producer Process - omit • Producer process inserts nextp into the shared buffer region buffer when( count < n) { pool[in] = nextp; in:= (in+1) % n; count++; }

  50. Critical Regions Bounded Buffer Consumer Process - omit • Consumer process removes an item from the shared buffer and puts it in nextc region buffer when (count > 0) { nextc = pool[out]; out = (out+1) % n; count--; }

More Related