Chapter 6 : Process Synchronization

1. Chapter 6:Process Synchronization CPCS361 – OperatingSystems I

2. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Atomic Transactions

3. Objectives • To introduce the critical-section problem, whose solutions can be used to ensure the consistency of shared data • To present both software and hardware solutions of the critical-section problem • To introduce the concept of an atomic transaction and describe mechanisms to ensure atomicity

4. Background Cooperating processes can either directly share a logical address space (i.e. both code and data) or be allowed to share data only through files or messages Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes

5. Background Suppose that we wanted to provide a solution to the consumer-producer problem that fills all the buffers. This can be done by: Having an integer count that keeps track of the number of full buffers Initially, count is set to 0 It is incremented by the producer after it produces a new buffer and is decremented by the consumer after it consumes a buffer

6. Producer while (true) { /* produce an item and put in nextProduced */ while (count == BUFFER_SIZE) ; // do nothing buffer [in] = nextProduced; in = (in + 1) % BUFFER_SIZE; count++; }

7. Consumer while (true) { while (count == 0) ; // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; /* consume the item in nextConsumed */ }

8. Race Condition Producer and consumer routines are correct separately they may not function correctly when executed concurrently Example: count = 5; concurrently: producer executes count++; consumer executes count--; count may be 4, 5, or 6! The only correct result is 5, if producer and consumer execute separately

9. Race Condition count++ and count-- could be implemented as register1 = countregister1 = register1 + 1count = register1 register2 = countregister2 = register2 - 1count = register2

10. Race Condition Consider this executioninterleaving with “count = 5” initially: S0: producerregister1 = count {register1 = 5} S1: producerregister1 = register1 + 1 {register1 = 6} S2: consumerregister2 = count {register2 = 5} S3: consumerregister2 = register2 - 1 {register2 = 4} Then, either: S4: producercount = register1 {count = 6 } S5: consumercount = register2 {count = 4} or: S4: consumercount = register2 {count = 4} S5: producercount = register1 {count = 6 } register1 = countregister1 = register1 + 1count = register1 register2 = countregister2 = register2 - 1count = register2

11. Race Condition Incorrect state of count, because it is allowed for both processes to manipulate the variable count concurrently; this is called race condition. Process synchronizationandcoordinationis needed. register1 = countregister1 = register1 + 1count = register1 register2 = countregister2 = register2 - 1count = register2

12. Critical-Section Problem Critical section: a process segment of code in which a process may be changing common variables, updating a table, writing a file, and so on When one process is executing in its critical section, no other process is allowed to execute in its critical section do { entry section critical section exit section remainder section } while (TRUE);

13. Solution to Critical-Section Problem A solution to the critical-section problem must satisfy the following three requirements: 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 only those processes that are not executing in their remainder sections can participate in the decision on which will enter its critical section next, and this selection cannot be postponed indefinitely

14. Solution to Critical-Section Problem 3.Bounded Waiting- A bound, or limit 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 theN processes

15. Peterson’s Solution Solution is restricted to two processes that alternate execution between their critical sections and reminder sections

16. Peterson’s Solution The two processes share two variables: int turn; booleanflag[2] The variable turn indicates whose turn it is to enter the critical section. The flag array is used to indicate if a process is ready to enter the critical section. flag[i]= true implies that process Pi is ready! If both processes try to enter at the same time, turn will be set to both i and j at roughly the same time. Only one of these will last; the other will occur but will be overwritten immediately The eventual value of turn decides which of the two processes is allowed to enter its critical section first

17. do { flag[i] = TRUE; turn = j; while (flag[j] && turn == j); critical section flag[i] = FALSE; remainder section } while (TRUE); Algorithm for Processes Pi and Pj Pi Pj do { flag[j] = TRUE; turn = i; while (flag[i] && turn == i); critical section flag[j] = FALSE; remainder section } while (TRUE);

18. Algorithm for Processes Pi and Pj Mutex is preserved: if Piand Pjcan be executing in their critical section at the same time, then flag[i] = flag[j] = true. Since turn can be either i or j one of the processes must have successfully executing the while statement Piwill reset flag[i] to false allowingPjto enter its critical section (progress) after at most one entry by Pi(bounded waiting)

19. Synchronization Hardware Many systems provide hardware support for critical section code Uniprocessors – could disable interrupts Currently running code would execute without preemption Generally too inefficient on multiprocessor systems Modern machines provide special atomic hardware instructions Atomic = non-interruptable Either test memory word and set value Or swap contents of two memory words

20. Synchronization Hardware Race conditions are prevented by requiring that critical regions be protected by locks A process must acquire a lock before entering a critical section; it releases the lock when it exits the critical section

21. Solution to Critical-section Problem Using Locks do { acquire lock critical section release lock remainder section } while (TRUE);

22. Semaphore Semaphore S – integer variable Less complicated Accessed only through two standard atomic /indivisible operations (when one process modify the semaphore value, no other process can simultaneously modify that same semaphore): wait() and signal() Originally called P() andV() • wait (S) { • while S <= 0 • ; // no-op • S--; • } • signal (S) { • S++; • }

23. Semaphore as General Synchronization Tool 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 Also known as mutex locks Can implement a counting semaphore S as a binary semaphore Provides mutual exclusion • Semaphore mutex; // initialized to 1 • do { • wait (mutex); • // Critical Section • signal (mutex); • // remainder section • } while (TRUE);

24. 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 . . . . . . P0 P1 wait (Q); wait (S); wait (S); wait (Q); can not be executed  deadlock signal (S); signal (Q); signal (Q); signal (S);

25. Deadlock and Starvation Starvation– indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended. It may occur when processes are added or removed from the semaphore’s list in LIFO order.

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

27. Bounded-Buffer Problem Solution to the bounded-buffer problem using semaphores Pool ofn buffers, each can hold one item Semaphore mutex initialized to the value 1 Semaphore fullinitialized to the value 0 Semaphore empty initialized to the value n

28. Bounded Buffer Problem (Cont.) Structure of theproducer process do { // produce an item in nextp wait (empty); wait (mutex); // add the item to the buffer signal (mutex); signal(full); } while (TRUE); Structure of the consumer process do { wait(full); wait (mutex); // remove an item from buffer to // nextc signal (mutex); signal (empty); // consume the item in nextc } while (TRUE);

29. Readers-Writers Problem A data set is shared among a number of concurrent processes Readers – only read the data set; they do not perform any updates Writers – can update (to read and write) Problem – Allow multiple readers to read at the same time. Only one single writer can access the shared data at the same time (writers have exclusive access to the shared data). No reader will be kept waiting unless a writer has already obtained permission to use the shared object.

30. Readers-Writers Problem Solution: Shared Data Integer readcount initialized to 0 keeps track of how many processes are currently reading the object Semaphoremutex initialized to 1 to ensure mutual exclusion when the variable readcount is updated Semaphore wrt initialized to 1 mutual exclusion for the writers used by the first or last reader that enters or exits the critical section

31. Readers-Writers Problem (Cont.) Structure of a writer process do { wait (wrt) ; // writing is performed signal (wrt) ; } while (TRUE); Structure of a reader process do { wait (mutex) ; readcount ++ ; if (readcount == 1) wait (wrt) ; signal (mutex); // reading is performed wait (mutex) ; readcount --; if (readcount == 0) signal (wrt) ; signal (mutex) ; } while (TRUE);

32. Dining-Philosophers Problem Shared data Bowl of rice (data set) Semaphore chopstick [5] initialized to 1 Eat Think

33. Dining-Philosophers Problem (Cont.) The structure of Philosopheri : do { wait ( chopstick[i] ); wait ( chopstick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think } while (TRUE);

34. End of Chapter 6