![Producer
while (true) {
/* produce an item in next
produced */
while (counter == BUFFER_SIZE) ;
/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}](https://image.slidesharecdn.com/chapter5-processsynchronizationunit2-250304095324-be362599/85/Chapter-5-Process-Synchronization-Unit-2-ppt-4-320.jpg)
![Consumer
while (true) {
while (counter == 0)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next
consumed */
}](https://image.slidesharecdn.com/chapter5-processsynchronizationunit2-250304095324-be362599/85/Chapter-5-Process-Synchronization-Unit-2-ppt-5-320.jpg)
Chapter 5-Process Synchronization (Unit 2).ppt
- 2. Chapter 5: Process Synchronization • Background • The Critical-Section Problem • Peterson’s Solution
- 3. Background • Processes can execute concurrently – May be interrupted at any time, partially completing execution • Concurrent access to shared data may result in data inconsistency • Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes • Illustration of the problem: Suppose that we wanted to provide a solution to the consumer- producer problem that fills all the buffers. One possibility is to add an integer variable counter, initialized to 0. Counter is incremented every time we add a new item to the buffer and is decremented every time we remove one item from the buffer
- 4. Producer while (true) { /* produce an item in next produced */ while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; counter++; }
- 5. Consumer while (true) { while (counter == 0) ; /* do nothing */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; /* consume the item in next consumed */ }
- 6. Race Condition • counter++ could be implemented as register1 = counter register1 = register1 + 1 counter = register1 • counter-- could be implemented as register2 = counter register2 = register2 - 1 counter = register2 • Consider this execution interleaving with “count = 5” initially: S0: producer execute register1 = counter {register1 = 5} S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = counter {register2 = 5} S3: consumer execute register2 = register2 – 1 {register2 = 4} S4: producer execute counter = register1 {counter = 6 } S5: consumer execute counter = register2 {counter = 4} • A situation like this, where 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, is called a race condition.
- 7. Critical Section Problem • Consider system of n processes {p0, p1, … pn-1} • Each process has critical section segment of code – Process may be changing common variables, updating table, writing file, etc – When one process in critical section, no other may be in its critical section • Critical section problem is to design protocol to solve this • Each process must ask permission to enter critical section in entry section, may follow critical section with exit section, then remainder section
- 8. Critical Section • General structure of process Pi
- 9. 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 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
- 10. Critical-Section Handling in OS Two approaches depending on if kernel is preemptive or non- preemptive – Preemptive – allows preemption of process when running in kernel mode – Non-preemptive – runs until exits kernel mode, blocks, or voluntarily yields CPU • Essentially free of race conditions in kernel mode