Process Synchronization: Ensuring Orderly Execution of Cooperating Processes

1. ITEC 502 컴퓨터 시스템 및 실습 Chapter 3-1: Process Synchronization Mi-Jung Choi mjchoi@postech.ac.kr DPNM Lab. Dept. of CSE, POSTECH

2. Contents • Race Conditions • Critical Regions • Mutual Exclusion with Busy Waiting • Sleep and Wakeup • Semaphores • Mutexes

3. Background • Concurrent access to shared data may result in data inconsistency • Maintaining dataconsistency requires mechanisms to ensure the orderly execution of cooperating processes • Suppose that we wanted to provide a solution to the consumer-producer problem that fills all the buffers • We can do so by having an integer counter that keeps track of the number of items in the buffer • Initially, counter is set to 0. • It is incremented by the producer after it produces a new item • It is decremented by the consumer after it consumes a item

4. Interprocess Communication • IPC for short • Race conditions • may occur in a system where multiple processes work together • situations where the final outcome depends on who runs precisely when • Example: spool system

5. Race Condition (1) • Although the producer and consumer routines are correct separately, they may not function correctly when executed concurrently • Suppose • that the value of the variable counter is currently 5 and • that the producer and consumer execute the statements “counter++” and “counter--” concurrently • Following the execution of these two statements, the value of the variable counter may be 4, 5, or 6 • Why?

6. Race Condition (2) • We would arrive at this incorrect state • Because we allowed both processes to manipulate the variable counter concurrently • 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 the race condition • We need to ensure that only one process at a time can manipulate the variable counter • We require that the processes be synchronized in some way

7. Critical-Region (CR) Problem • A system consisting of n processes {P0, P1, …, Pn-1} • Each process has a segment of code, called a critical region, where the process may change common variables, updating a table, writing a file, and so forth • The system requires that no two processes are executing in their critical region at the same time • Solution to the critical-region problem • To design a protocol that the processes can use to cooperate • Each process must request permission to enter its CR • The section of code implementing this request is the entry section • The CR may be followed by an exit section • The remaining code is the remainder section

8. Do { entry section critical region exit section remainder section } while ( TRUE ); Critical-Region Problem • The general structure of a typical process Pi

9. Critical Regions (1) • Mutual exclusion to avoid race conditions • Four conditions to provide mutual exclusion • C1: No two processes simultaneously in CR • C2: No assumptions about speeds or numbers of CPUs • C3: No process outside its CR may block another process • C4: No process should have to wait forever to enter its CR

10. Critical Regions (2) Mutual exclusion using critical regions - This is what we want

11. Solution to Critical-Region Problem • A solution to the critical-region problem must satisfy the following three requirements: 1. (c1) Mutual Exclusion - If process Pi is executing in its critical region, then no other processes can be executing in their critical regions 2. (c3) Progress - If no process is executing in its critical region and there exist some processes that wish to enter their critical region, then the selection of the processes that will enter the critical region next cannot be postponed indefinitely – deadlock-free condition 3. (c4) Bounded Waiting - A bound must exist on the number of times that other processes are allowed to enter their critical regions after a process has made a request to enter its critical region and before that request is granted – starvation-free condition • (c2) Assume that each process executes at a nonzero speed • (c2) No assumption concerning relative speed of the n processes

12. Peterson’s Solution for critical region problem • Two process {Pi, Pj} solution • Software-based solution • Assume that the LOAD and STORE instructions are atomic; that is, cannot be interrupted • The two processes share two variables: • int turn; • Boolean flag[2] • The variable turn indicates whose turn it is to enter the critical region • The flag array is used to indicate if a process is ready to enter the critical region • flag[i] = true implies that processPiis ready!

13. Algorithm for Process Pi do { flag[i] = TRUE; turn = j; while ( flag[j] && turn == j); CRITICAL Region flag[i] = FALSE; REMAINDER Section } while (TRUE); // entry section // exit section

14. Peterson’s Solution satisfies 3 conditions • Mutual Exclusion • Each Pi enters its critical region only if either flag[j]==false or turn==i • Each Pi enters its critical region with flag[i]==true • Both Pi and Pj cannot enter their critical region at the same time • Progress • Pi can be stuck only if either flag[j]==true and turn==j • Bounded Waiting • Pi will enter the critical region after at most one entry by Pj

15. Mutual Exclusion with Busy Waiting (1) • Disabling interrupts • disable interrupts while a process in CR • what happens if there is another CPU??  violates C2! • Lock variables • shared (lock) variable, initially 0 • set it to 1 to enter and to 0 to leave CR • do not solve the problem at all! • Strict alternation • processes A and B enter CR alternatively • violates C3

16. Mutual Exclusion with Busy Waiting (2) Peterson's solution for achieving mutual exclusion

17. Mutual Exclusion with Busy Waiting (3) Entering and leaving a critical region using the TSL instruction TSL RX, LOCK (1) copy value at LOCK to RX (2) store non-zero at LOCK * these two steps are indivisible!

18. Sleep and Wakeup (1) • Both Peterson’s and TSL solutions are correct, but… • they require busy waiting  waste CPU cycles • also, the priority inversion problem may occur!  Blocking sys. calls preferable to busy-waiting • Sleep() • block itself • Wakeup(pid) • unblock another process ‘pid’

19. Sleep and Wakeup (2) Producer-consumer problem with fatal race condition

20. Semaphore (1) • The various hardware-based solutions to the critical region problem • complicated for application programmers to use • To overcome this difficulty • Semaphore may be used • Semaphore is … • Synchronization tool that does not require busy waiting • Semaphore S–integer variable • Two standard operations to modify S: down() and up() • The modification of the semaphore is atomic • When one process modifies the semaphore value, no other process can simultaneously modify that same semaphore value • less complicated to use

21. Semaphore (2) • Semaphore Alphabet

22. Semaphores (3) • Problem with sleep/wakeup • wakeup signal can be lost  wakeup waiting bit • what if there are many processes involved?? we need a counter for wakeups! motivation of semaphores • Semaphores • integer variables with atomic operations down() and up() • down(s): • If (s == 0) then sleep() • else s = s-1 • up(s): • s = s+1 • if there is another process sleeping on ‘s’, wake it up

23. Usage of Semaphore (1) • Binary semaphore • Integer value can range only between 0 and 1 • Which is refer to as mutex locks • Binary semaphore for solving the critical-region problem for multiple processes • n processes share a semaphore, mutex • mutex is initialized to 1 • The structure of a processPi • do • { • down (mutex); • CRITICAL Region • up (mutex); • REMAINDER Section • } while (TRUE);

24. Usage of Semaphore (2) - Binary Semaphore • Does previous code satisfy three requirements of CR problem • Mutual exclusion • Progress • Bounded waiting • The third requirement is not guaranteed as a default • It usually depends on the implementation of down() function • Ex, Linux sem_wait() does not guarantee the bounded waiting request

25. Semaphores (4) The producer-consumer problem using semaphores

26. Semaphores (5) The producer-consumer problem using semaphores void producer(void) { int item; while (TRUE) { item = produce_item(); down(&empty); down(&mutex); insert_item(item); up(&mutex); up(&full); } } void consumer(void) { int item; while (TRUE) { down(&full); down(&mutex); remove_item(item); up(&mutex); up(&empty); consume_item(item); } } #define N 100 typedef int semaphore; semaphore mutex = 1; semaphore empty = N; semaphore full = 0;

27. Mutexes Implementation of mutex_lock and mutex_unlock  Can be easily implemented in user space with the help of TSL

28. Summary • Cooperating processes that share data have critical region of code each of which is in use by only one process at a time • Three requirements for critical region problem • Mutual Exclusion, Progress, Bounded Waiting • The main disadvantage of these solution is that they all require busy waiting. Semaphore overcome this difficulty • In the next class: • Semaphore can be used to solve various synchronization problems • The bounded-buffer, The readers-writers, The dining-philosophers problem problems • Those are examples of a large class of concurrency-control problems • The solution should be deadlock-free ad starvation-free

29. Review • Race Conditions • Critical Regions • Mutual Exclusion with Busy Waiting • Sleep and Wakeup • Semaphores • Mutexes