Chapter 6 Synchronization Da-Wei Chang CSIE.NCKU Source: Abraham Silberschatz, Peter B. Galvin, and Greg Gagne, "Operating System Concepts", 9th Edition, Wiley. 1
Outline Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Atomic Transactions 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 cooperating processes: processes that access the shared data Suppose that we wanted to provide a solution to the consumer-producer problem that fills all the buffers. use an integer count keeps track of the number of full buffers Initially set to 0 Incremented by the producer after it produces a new buffer Decremented by the consumer after it consumes a buffer 3
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++; 4
Consumer while (true) } { while (count == 0) ; // do nothing nextconsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; /* consume the item in nextconsumed */ 5
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: S0: producer execute register1 = count {register1 = 5} S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2-1 {register2 = 4} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4} Race condition 6
Critical Section Critical section A segment of code, in which the process may update shared data When a process is in the critical section, others cannot enter that section no two processes in the same critical section at the same time Critical section problem Design a protocol that processes can use to coordinate Entry section: code to try/request to enter the critical section Exit section: code that follows the critical section 7
Critical Section do { entry section critical section exit section remainder section } while (TRUE) 8
Solution to Critical-Section Problem A solution should satisfy the following requirements 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 guarantee a given process will finally be selected Assume that each process executes at a nonzero speed No assumption concerning relative speed of the N processes 9
Peterson s Solution Two-process solution; a software based solution Assume that the LOAD and STORE instructions are atomic; that is, cannot be interrupted. The two processes share two variables: intturn; Boolean flag[2]; The variable turn indicates whose turn it is to enter the critical section The flag array is used to indicate whether or not a process is ready to enter the critical section flag[i] = TRUE implies that process P i is ready! 10
Peterson s Solution do { Algorithm for Process P i flag[i] = TRUE; turn = j; while ( flag[j] && turn == j); // you first CRITICAL SECTION flag[i] = FALSE; // exit REMAINDER SECTION do { Algorithm for Process P j flag[j] = TRUE; turn = i; while ( flag[i] && turn == i); // you first CRITICAL SECTION flag[j] = FALSE; // exit REMAINDER SECTION } while (TRUE); } while (TRUE); 11
Peterson s Solution Mutual exclusion is met turn can either be i or j Progress and bounded-waiting are met Once Pj exits, it sets flag[j] to false, allows Pi to enter If Pj resets flag[j] to true, it must also set turn to i Allow Pi to enter Pi will enter critical section after at most one entry by Pj (bounded-waiting) Selection will not be postponed forever (progress) 12
Critical Sections and Locks Any solution to the critical section problem requires a simple tool a lock (ensure mutual exclusion) do { Acquire lock Critical section Release lock Remainder section } while (TRUE) Lock can be implemented in different ways. 13
Synchronization Hardware Many systems provide hardware support for locks Uniprocessor could disable interrupts Currently running code would execute without preemption The approach used by non-preemptive kernels to protect shared data in the kernels Generally too inefficient on multiprocessor systems Operating systems using this not broadly scalable Need to ask other processors to disable interrupts Clocks may stop in the critical section 14
Synchronization Hardware Modern machines provide special atomic hardware instructions Atomic = non-interruptable Either test memory word and set value, or swap contents of two memory words 15
TestAndSet Instruction Definition boolean TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv; } Done by a single instruction 16
Solution using TestAndSet Shared boolean variable lock, initialized to FALSE. Solution do { while ( TestAndSet (&lock) ) ; // do nothing.. critical section here lock = FALSE;.. remainder section here } while (TRUE); 0 1 1 1 17
Swap Instruction Definition void Swap (boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp: } Done by a single instruction 18
Solution using Swap Shared Boolean variable lock initialized to FALSE; Each process has a local Boolean variable key. Solution: Used for swapping with lock do { key = TRUE; while (key == TRUE) Swap ( &lock, &key );.. critical section here lock = FALSE;.. remainder section here } while (TRUE); Lock: TRUE, key: FALSE 19
Synchronization Hardware The above two examples do not satisfy bounded waiting The following code satisfy all the three requirements Boolean waiting[n], lock; do { waiting[i] = TRUE; // wish to acquire the lock key = TRUE; while (waiting[i] && key) key = TestandSet(&lock); // try to acquire the lock waiting[i] = FALSE; // critical section here. // j = (i+1)%n; while ( (j!= i) &&!waiting[j] ) j = (j+1)%n; // keep locked and allow the // next to come in if ( j == i ) lock = FALSE; else waiting[j] = FALSE; // remainder section here. // } while (TRUE); 20
Semaphore A less complicated syn. interface to programmers Typical semaphore implementations do NOT require busy waiting Semaphore S integer variable Two standard operations modify S: wait() and signal() Originally called P() and V() Can only be accessed via two indivisible (atomic) operations wait (S) { while S <= 0 // atomic for each iteration ; // no-op // iteration: if S>0, S--; else, no-op and test again S--; } signal (S) { S++; } // atomic 21
Semaphore as General Synchronization Tool Counting semaphore integer value can range over an unrestricted domain Binarysemaphore integer value can range only between 0 and 1; can be simpler to implement Also known as mutex locks A counting semaphore S can be used to implement a binary semaphore 22
Semaphore as General Synchronization Tool Provides mutual exclusion Semaphore S; // initialized to 1 wait (S); Critical Section signal (S); Other usages on semaphores Control the usage of resources with N instances S is initialized to N Synchronization between processes S is initialized to 0 23
Semaphore Implementation Previous semaphore definition requires busy waiting Note that applications may spend lots of time in critical sections. In this case, busy waiting is not a good approach. Solution Sleep/block instead of busy waiting 24
Semaphore Implementation WITHOUT Busy Waiting In addition to the semaphore value, each semaphore has an associated waiting queue Require blocking/waking-up a process block switch process state to waiting remove the process from the ready queue wakeup switch process state to ready place the process in the ready queue Both operations may lead to the invocation of the scheduler 25
Semaphore Implementation WITHOUT Busy waiting (Cont.) Implementation of wait: wait (S){ value--; if (value < 0) { // the value can be negative # of processes waiting add this process to the waiting queue block(); /* suspend the process */ } } Implementation of signal: Signal (S){ value++; if (value <= 0) { remove a process P from the waiting queue wakeup(p); } } 26
Semaphore Implementation The list of waiting processes? A list of PCBs FIFO ensure bounded waiting Must guarantee that no two processes can execute wait() and signal() on the same semaphore at the same time The implementation in the previous slide should be atomic Thus, implementation becomes the critical section problem where the wait and signal code are placed in the critical section. For uniprocessor disable interrupt For MP typically use spinlocks ( busy waiting ) Acceptable for busy waiting in critical sections of the wait() and signal() operations since they are short 27
Deadlock and Starvation Deadlock two or more processes are waiting infinitely 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 infinite blocking. A process may never be removed from the semaphore queue in which it is suspended. 28
Classical Problems of Synchronization Bounded-Buffer Problem Readers and Writers Problem Dining-Philosophers Problem We will try to use semaphores to solve the problems 29
Bounded-Buffer Problem N buffers, each one can hold an item Semaphore mutex initialized to the value 1 Semaphore full initialized to the value 0 Semaphore empty initialized to the value N Players Producers produce full buffers, wait for empty buffers Consumers produce empty buffers, wait for full buffers 30
Bounded Buffer Problem (Cont.) The structure of the producer process do { // produce an item wait (empty); wait (mutex); // add the item to the buffer signal (mutex); signal (full); } while (true); 31
Bounded Buffer Problem (Cont.) 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); 32
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 How to allow multiple readers to read at the same time? Of course, only one single writer can access the shared data at the same time. Shared Data Data set Integer readcount initialized to 0. // number of readers Semaphore mutex initialized to 1. // mutex on readcount Semaphore wrt initialized to 1. // contention with a writer 33
Readers-Writers Problem (Cont.) The structure of a writer process do { wait (wrt) ; // writing is performed signal (wrt) ; } while (true); 34
Readers-Writers Problem (Cont.) The structure of a reader process do { wait (mutex) ; // mutex: for updating and maintaining readcount readcount ++ ; if (readercount == 1) wait (wrt) ; // the following readers do not wait(wrt) signal (mutex) // reading is performed wait (mutex) ; readcount -- ; if (redacount == 0) signal (wrt) ; signal (mutex) ; } while (true) If a writer is in the critical section and n readers are waiting, then one reader is blocked on wrt and the other n-1 readers are blocked on mutex On signal (wrt), we can wakeup a set of readers or a single writer 35
Reader-Writer Locks Some systems support reader-writer locks Using the reader-writer locks Specify the lock mode: read or write Useful in the following situations When it is easy to identify r/w access mode More readers than writers 36
Dining-Philosophers Problem 5 Philosophers, spending their lives thinking and eating Get hungry try to get the chopsticks next to him Pick up only one chopstick at a time Eat when he gets both Putdown both chopsticks when he is finished eating Shared data Bowl of rice (data set) Semaphores chopstick [5] initialized to 1 37
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) ; 38
Dining-Philosophers Problem The solution above may lead to deadlock e.g., all philosophers pick up their left chopsticks Remedies At most 4 philosophers Pick up chopsticks when both are available Odd philosophers: left, right; even philosophers: right, left. We will present a solution later 39
Problems with Semaphores Using semaphores incorrectly can result in bugs that are hard to detect Incorrect use of semaphore operations: signal (mutex). wait (mutex) race wait (mutex) wait (mutex) deadlock Omitting of wait (mutex) or signal (mutex) (or both) race or deadlock The bugs are hard to detect Faults don t always take place 40
Monitors A high-level abstraction that provides a convenient and effective mechanism for process synchronization monitor monitor-name {... shared variable declarations } procedure P1 ( ) {. } procedure Pn ( ) { } Initialization code (.) { } Programmers provide the operations Monitor makes sure only one process may be active within the monitor at a time 41
Schematic View of a Monitor A list of processes waiting for entering the monitor 42
Monitors With monitors, programmers do not need to code the synchronization constraint However, the function provided by monitors is limited In many cases, programmers still need to define additional syn mechanisms Use condition variables 43
Condition Variables condition x, y; Two operations on a condition variable x.wait() a process that invokes the operation is suspended x.signal() resumes one of processes (if any) that invoked x.wait () No effect if no one is waiting No values, just suspend and resume Different from semaphores Using them incorrectly are still hard-to-be-detected bugs 44
Monitor with Condition Variables If Q wait X and then P signal X - P is now in monitor, but it will make Q become active in the monitor -Two possibilities A. signal & wait : Q becomes active immediately, P leaves B. signal & continue: Q becomes active after P leaves 45
Solution to Dining Philosophers Code for each philosopher: DP.pickup(i); // DP is the monitor eat DP.putdown(i); 46
Solution to Dining Philosophers (cont.) A philosopher picks up chopsticks only when both of them are available monitor DP { enum { THINKING; HUNGRY, EATING) state [5] ; condition self [5]; //delay herself when she is hungry but unable to obtain the chopsticks void pickup (int i) { state[i] = HUNGRY; test(i); if (state[i]!= EATING) self [i].wait; } void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); // allow the philosopher on the left to finish her pickup test((i + 1) % 5); // allow the philosopher on the right to finish her pickup } 47
Solution to Dining Philosophers (cont.) void test (int i) { if ( (state[(i + 4) % 5]!= EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5]!= EATING) ) { state[i] = EATING ; self[i].signal () ; } } initialization_code() { for (int i = 0; i < 5; i++) state[i] = THINKING; } } // end of monitor 48
Implementing a Monitor Using Semaphores Use a semaphore mutex (init. as 1) for each monitor wait(mutex) before entering the monitor signal(mutex) after leaving the monitor A signaling process may wait until the resumed process to leave or wait Use another semaphore next (init. as 0) Signaling process can suspend on it Next_count Count the number of processes suspend on next 49
Implementing a Monitor Using Semaphores Each external procedure F is replaced by wait (mutex); F if (next_count >0 ) else signal(next); signal(mutex); Wakeup a signaling process Allow another process to come in Each condition variable is implemented by using x_sem : semaphore corresponds to x (init. as 0) x_count: number of processes waiting on x_sem 50
Implementing a Monitor Using Semaphores x.wait() { x_count++; if (next_count >0 ) else wait(x_sem); x_count--; } x.signal() { if (x_count >0 ) { next_count++; signal(x_sem); wait(next); next_count--; } } signal(next); signal(mutex); wait here. have been waken wait here. have been waken 51
Process Resuming Order Which process (waiting for the monitor) should be resumed first? FCFS Priority Users can specify priority on suspension x.wait(priority) 52
Incorrect Use of Monitor Access a resource without being granted Never release the resource Release a resource that the process doesn t have Release the resource twice Monitors make sure only one process is in it at a time, but it can not solve all the problems related to resource allocation/deallocation. 53
Synchronization Examples Solaris Windows XP Linux Pthreads 54
Solaris Synchronization Implements a variety of locks to support multitasking, multithreading (including real-time threads), and multiprocessing Uses adaptive mutexes for efficiency when protecting data from short code segments If the lock holder is running busy waiting Otherwise blocking Uses condition variables and semaphores for longer sections of code that require shared-data access readers-writers locks are also provided Uses turnstiles to order the list of threads waiting to acquire either an adaptive mutex or reader-writer lock Organized according to Priority Inheritance Protocol (PIP) to avoid priority inversion 55
Priority Inversion A problem in real-time systems 56
Priority Inheritance Protocol (PIP) Some level of priority inversion can not be avoided!! 57
Windows XP Synchronization Uses interrupt masks to protect access to global resources on uniprocessor systems Uses spinlocks on multiprocessor systems Also provides dispatcher objects which may act as either mutexes and semaphores Dispatcher objects may also provide events An event acts much like a condition variable You can wait on them 58
Linux Synchronization Linux disables interrupts to implement short critical sections Linux provides semaphores spin locks Reader-writer locks/semaphores 59
Pthreads Synchronization Pthreads API is OS-independent It provides: mutex locks condition variables Non-portable extensions include: reader-writer locks spin locks 60
Atomic Transactions In addition to mutual exclusion, sometimes a critical section should be performed all or none Even with the presence of failures Atomicity A concern in database systems OS borrows database techniques Transaction A collection of instructions that perform a single function A sequence of RW operations terminated by either commit or abort Should be done all or none On abort roll back ( to undo the updates ) 61
Atomic Transactions Various types of storage Volatile storage Not survive system crashes E.g., memory, cache Non-volatile storage Usually survive system crashes E.g., disk, tape Subject to failure Stable storage Never lose its data 62
Log-based Recovery Record all the modifications on the stable storage Write-ahead logging (WAL) Log before write Log records Write log Transaction id, data id, old value, new value Special log Transaction start, commit, abort Logging has performance penalty Two writes are needed for a write request Space overhead for the log space 63
Log-based Recovery Two operations used in the recovery procedure Undo (Ti) Redo (Ti) Recovery procedure Check the entire log space, for each transaction T that has the transaction start log Has commit log redo No commit log undo Time consuming Check the whole log space Redo a lot of transactions that have finished their data update 64
Checkpoints No need to check the entire log space Periodically perform checkpoints, which Output log records to the stable storage Output the modified data to the stable storage Output log record <checkpoint> Recovery procedure Only the transactions after the last checkpoint need to be undo/redo 65
Concurrent Atomic Transactions Consider multiple concurrent transactions Serializability can be maintained by executing each transaction in a critical section All transactions share a common mutex Too restrictive Concurrency-control algorithms Allow transactions to overlap their execution while maintaining serializability 66
Serializability Serial schedule: a schedule that the transactions are not overlapped A nonserial schedule may still be correct Conflicting operations Oi, Oj between two different transactions, - operate on the same data - at least a write If Oi and Oj are not conflict, they can swap T0 Read(A) Write(A) Read(B) Write(B) T1 Read(A) Write(A) Read(B) Write(B) A conflict serializable schedule serial schedule swap operations 67
Ensuring Serializability Two ways to ensure conflict serializability Two phase locking protocol Time-stamp-based protocol Two phase locking protocol Use share or exclusive lock for data access Similar to the reader-writer locks Each transaction issues lock/unlock in two phases Growing phase: lock only, cannot unlock Shrinking phase: unlock only, cannot lock Initially in growing phase, enters the shrinking phrase when the transaction performs the first unlock Deadlock can occur Lock ordering can prevent deadlock (see chapter 7) 68
Ensuring Serializability Time-stamp-based protocol Each transaction is associated with a timestamp TS(Ti) when it begins TS(Ti) < TS(Tj) this protocol produces the schedule that is equal to a serial schedule in which Ti executes before Tj Each data Q has two timestamps WT(Q) : timestamp of the last transaction writing Q RT(Q) : timestamp of the last transaction reading Q 69
Ensuring Serializability Time-stamp-based protocol (cont.) When Ti issues read(q) If TS(Ti) < WT(Q): roll back Ti If TS(Ti) >= WT(Q) Perform read update RT(Q) = max (RT(Q), TS(Ti)) When Ti issues write(q) If TS(Ti) < RT(Q): roll back Ti If TS(Ti) < WT(Q): roll back Ti Otherwise perform write update WT(Q) 70