1. 6.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors (skip) Synchronization Examples (skip) Atomic Transactions (skip)

2. 6.2 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 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 (skip)

3. 6.3 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 6.1 Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency 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 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. (reference to Section 3.4.1, power point 27 --- 31)

4. 6.4 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 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++; } while (true) { while (count == 0) ; // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; /* consume the item in nextConsumed */ } Consumer

5. 6.5 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Race Condition count++ could be implemented as register1 = count register1 = register1 + 1 count = register1 count-- could be implemented as register2 = count register2 = register2 - 1 count = register2 Consider this execution interleaving with “count = 5” initially: T0: producer execute register1 = count {register1 = 5} T1: producer execute register1 = register1 + 1 {register1 = 6} T2: consumer execute register2 = count {register2 = 5} T3: consumer execute register2 = register2 - 1 {register2 = 4} T4: producer execute count = register1 {count = 6 } T5: consumer execute count = register2 {count = 4} If the order T4 and T5 is reversed, then the final state is count = 6

6. 6.6 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 6.2 Solution to Critical-Section Problem Critical Section: A segment of code in which the process may be changing common (shared) variables, updating a table, writing a file, etc. Figure 6.1 General Structure of a typical process P i entry section exit section

7. 6.7 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Requirements of Solutions to Critical Sections 1. Mutual Exclusion - If process P i 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

8. 6.8 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Example kernel data structure that is subject to race conditions: List of open files in the OS Data structure for free/allocated memory Process lists Data structure for interrupts handling Approaches in handling critical sections in OS: Preemptive kernels Nonpreemptive kernels A preemptive kernel is more suitable for real-time programming –--- it is more responsive

9. 6.9 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 6.3 Peterson’s Solution Two process 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 section. The flag array is used to indicate if a process is ready to enter the critical section. flag[i] = true implies that process P i is ready!

10. 6.10 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Algorithm for Process P i while (true) { flag[i] = TRUE; turn = j; // j is 1 - i while ( flag[j] && turn == j); CRITICAL SECTION flag[i] = FALSE; REMAINDER SECTION } To prove Peterson’s solution is correct: Mutual exclusion is preserved The progress requirement is satisfied The bounded-waiting requirement is met entry section exit section

11. 6.11 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 6.4 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  Operating systems using this not broadly scalable Modern machines provide special atomic hardware instructions  Atomic = non-interruptable Either test memory word and set value Or swap contents of two memory words

12. 6.12 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition TestAndSet Instruction n Definition: boolean TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv: } n Shared boolean variable lock initialized to false. n Solution using TestAndSet: while (true) { while ( TestAndSet (&lock )) ; // do nothing // critical section lock = FALSE; // remainder section }

13. 6.13 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Swap Instruction n Definition: void Swap (boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp: } n Shared boolean variable lock initialized to FALSE; Each process has a local boolean variable key. n Solution using Swap: while (true) { key = TRUE; while ( key == TRUE) Swap (&lock, &key ); // critical section lock = FALSE; // remainder section } Does not satisfy bounded-waiting

14. 6.14 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition n Common data structure: boolean waiting[n] and boolean lock; n Solution using TestAndSet: while (true) { waiting[i] = TRUE; key = TRUE; while ( waiting[i] && key) key = TestAndSet(&lock); waiting[i] = FALSE; // critical section j = (i+1) %n; while ( ( j != i) && !waiting[j] ) j = (j + 1) %n; if (j == i) lock = FALSE; else waiting[j] = FALSE; // remainder section } Bounded-waiting mutual exclusion with TestAndSet()

15. 6.15 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 6.5 Semaphore Synchronization tool that does not require busy waiting Semaphore S – integer variable accessed only through two standard atomic operations: wait( ) and signal( ), originally called P( ) and V( ) Less complicated: All modifications to the integer value of the semaphore must be executed indivisibly l wait (S) { while S <= 0 ; // no-op S--; } l signal (S) { S++; } n In wait(S), the testing of S (i.e. S <= 0) and S-- must be executed without interruption

16. 6.16 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 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);

17. 6.17 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Semaphore Usage Used in synchronization If two concurrent processes P 1 and P 2 must be synchronized such that S 2 in P 2 must be executed only after S 1 of P 1 semaphore synch; // initialized to 0 P 1 : S 1 ; signal(synch); P 2 : wait(synch); S 2 ;

18. 6.18 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Semaphore Implementation Must guarantee that no two processes can execute wait ( ) and signal ( ) on the same semaphore at the same time Thus, implementation becomes the critical section problem where the wait and signal code are placed in the critical section. Could now have busy waiting (called spinlock) in critical section implementation  But implementation code is short  Little busy waiting if critical section rarely occupied Note that applications may spend lots of time in critical sections and therefore this is not a good solution.

19. 6.19 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Semaphore Implementation with no Busy waiting (1) With each semaphore there is an associated waiting queue. Each entry in a waiting queue has two data items: value (of type integer): if value is negative, its magnitude is the number of processes waiting on this semaphore pointer to a process list: could be implemented as a queue to ensure bounded waiting typeof struct { int value; struct process *list; } semaphore; Two operations:  block – place the process invoking the operation on the appropriate waiting queue.  wakeup – remove one of processes in the waiting queue and place it in the ready queue.

20. 6.20 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Semaphore Implementation with no Busy waiting (2) Implementation of wait: wait(semaphore *S) { S->value--; if (S->value < 0) { add this process to S->list; block(); } Implementation of signal: signal(semaphore *S) { S->value++; if (S->value <= 0) { remove a process P from S->list; wakeup(P); }

21. 6.21 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 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 P 0 P 1 wait (S); wait (Q); wait (Q); wait (S);. signal (S); signal (Q); signal (Q); signal (S); Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended Priority Inversion - Scheduling problem when lower-priority process holds a lock needed by higher-priority process

22. 6.22 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Classical Problems of Synchronization Use semaphores for synchronization Bounded-Buffer Problem Readers and Writers Problem Dining-Philosophers Problem Bounded-Buffer Problem N buffers, each can hold one item Semaphore mutex (for mutual exclusion) initialized to the value 1 Semaphore full (counter for number of filled buffers) initialized to the value 0 Semaphore empty (counter for number of empty buffers) initialized to the value N.

23. 6.23 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Bounded Buffer Problem (Cont.) The structure of the producer process do { // produce an item in nextp wait (empty); wait (mutex); // add the item to the buffer signal (mutex); signal (full); } while (TRUE); The structure of the consumer process do { wait (full); wait (mutex); // remove an item from buffer signal (mutex); signal (empty); // consume the removed item } while (TRUE);

24. 6.24 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 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 both 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 must have exclusive access. Variation problems 1. No reader should be kept waiting unless a writer has obtained permission to use the shared object 2. Once a write is ready, that writer performs its write as soon as possible

25. 6.25 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Solution to Readers-Writers Problem In the first problem, writers may starve; in the second problem, reader may starve Solution to the first problem Shared Data  Data object  Semaphore mutex initialized to 1.  It is to ensure mutual exclusion when the variable readcount is updated.  Semaphore wrt initialized to 1.  It is used as a mutual exclusion semaphore for the writers. It is also used by the first or last reader that enters or exits the critical section.  Integer readcount initialized to 0.  It keeps track of how many processes are currently reading the object.

26. 6.26 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Readers-Writers Problem (Cont.) The structure of a writer process do { wait (wrt) ; // writing is performed signal (wrt) ; } while (TRUE); The 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);

27. 6.27 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Readers-Writers Problem (Cont.) If a writer is in the critical section, and n readers are waiting, then one reader is queued on wrt, and n-1 readers are queued on mutex When a writer executes signal(wrt), we may resume the execution of either the waiting readers or a single waiting writer. The selection is made by the scheduler of the OS. The readers-writers problem and its solution has been generalized to provide reader-writer locks. Reader-writer locks are useful in Applications where it is easy to identify which processes only read shared data and which only writes shared data Applications that have more readers than writers, where the overhead for setting up a reader-writer lock is compensated by the increased concurrency of allowing multiple readers

28. 6.28 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Dining-Philosophers Problem Shared data Bowl of rice (data set) Semaphore chopstick [5] initialized to 1 A representation of the need to allocate several resources among several processes in a dead-lock free and starvation-free manner.

29. 6.29 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Dining-Philosophers Problem (Cont.) The structure of Philosopher i: do { wait ( chopstick[i] ); wait ( chopStick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think } while (TRUE);

30. 6.30 Silberschatz, Galvin and Gagne ©2005 Operating System Principles Dining-Philosophers Problem (Cont.) The above solution could create a deadlock How to prevent deadlock Allow at most four philosophers to sit simultaneous in the table Allow a philosopher to pick up her chopsticks only if both chopsticks are available (pick up in a critical section) Use an asymmetric solution: an odd philosopher pick up first her left chopstick and then her right chopstick; whereas an even philosopher pick up first her right chopstick and then her left chopstick Note that a deadlock free solution does not eliminate the possibility of starvation

31. 6.31 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition 6.7 Problems with Semaphores Correct use of semaphore operations: wait(mutex) … signal(mutex) Incorrect use of semaphore operations: signal (mutex) …. wait (mutex) mutual exclusion violation wait (mutex) … wait (mutex) deadlock Omitting of wait (mutex) or signal (mutex) (or both) mutual exclusion violation or deadlock SKIP 6.7.1-6.7.4 Monitors, 6.8 -6.9