1. Chapter 6: Process Synchronization

2. 6.2Operating System Concepts Chapter 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Alternative Approaches X X X

3. 6.3Operating System Concepts 6.1 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 x=0; Thread 1:{for( i=0;i<10;i++)x=x+1;} Thread 2:{for( j=0;j<10;j++)x=x-1;} x

4. 6.4Operating System Concepts Illustration of the problem 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 full buffers. Initially, counter 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.

5. 6.5Operating System Concepts Producer-Consumer problem producer process produces information that is consumed by a consumer process producer: need to care buffer full consumer: need to care buffer empty p.257

6. 6.6Operating System Concepts 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++; } Buffer is full ? item nextProduced; while (true) { /* Produce an item */ while (((in + 1) % BUFFER SIZE count) == out) ; /* do nothing -- no free buffers */ buffer[in] = item; in = (in + 1) % BUFFER SIZE; } p.258

7. 6.7Operating System Concepts Consumer while (1) { while (count == 0) ; // do nothing nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; /* consume the item in nextConsumed } Buffer is empty? while (true) { while (in == out) ; // do nothing -- nothing to consume // remove an item from the buffer item = buffer[out]; out = (out + 1) % BUFFER SIZE; return item; } p.258

8. 6.8Operating System Concepts Synchronization integer count that keeps track of the number of full buffers count++ could be implemented as register = count register = register + 1 count = register initial count = 5 p.258 Machine Language

9. 6.9Operating System Concepts Asynchronization count++ could be implemented as register 1 = count register 1 = register 1 + 1 count = register 1 Count-- could be implemented as register 2 = count register 2 = register 2 - 1 count = register 2 Consider this execution interleaving with “count = 5” initially: T 0 : producer execute register 1 = count {register 1 = 5} T 1 : producer execute register 1 = register 1 + 1 {register 1 = 6} T 2 : consumer execute register 2 = count {register 2 = 5} T 3 : consumer execute register 2 = register 2 – 1 {register 2 = 4} T 4 : producer execute count = register 1 {count = 6 } T 5 : consumer execute count = register 2 {count = 4} => data inconsistency p.259 Machine cycle

10. 6.10Operating System Concepts Race Condition Several processes access and manipulate the same data concurrently and outcome of the execution depends on the particular order in which the access takes place To guard against the race condition, we need to ensure that processes be synchronized p.259

11. 6.11Operating System Concepts 6.2 Critical-Section Problem Consider system of n processes {p 0, p 1, … p n-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 p.259

12. 6.12Operating System Concepts 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 General structure of process p i is p.260

13. 6.13Operating System Concepts Solution to Critical-Section Problem 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 p.260

14. 6.14Operating System Concepts Kernel developer preemptive kernel (Solaris, IRIX, Linux 2.6 later) kernel allows a process to be preemptived while it is running in kernel-mode (need to care race condition) nonpreemptive kernel (Windows 2000,XP, Linux) kernel does not allows a process to be preemptive unless  kernel-mode process exits  kernel-mode process blocks  voluntarily yields control of the CPU We prefer preemptive kernel suitable for real-time programming more responsive p.261

15. 6.15Operating System Concepts 6.3 Peterson’s Solution Good algorithmic description of solving the problem 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! p.261

16. 6.16Operating System Concepts Algorithm for Process P i do { flag[ i ] = TRUE; turn = j; while ( flag[ j ] && turn == j ); CRITICAL SECTION flag[ i ] = FALSE; REMAINDER SECTION } while (TRUE); Provable that 1.Mutual exclusion is preserved 2.Progress requirement is satisfied 3.Bounded-waiting requirement is met p.262

17. 6.17Operating System Concepts Algorithm for Process P i Satisfies all three requirements t1t2t3t4 P 1 requesting P 0 requestingP 1 exitingP 1 requesting flag[0]FalseTrue flag[1]True FalseTrue turn0110 CRITICAL SECTION P 1 EnteringP 0 Waiting P 1 Entering => Mutual Exclusion P 0 WaitingP 0 Entering => Progress P 1 Waiting =>Bounded waiting do { flag[ 0] = TRUE; turn =1; while ( flag[ 1 ] && turn ==1 ); CRITICAL SECTION flag[ 0 ] = FALSE; REMAINDER SECTION } while (TRUE); do { flag[ 1 ] = TRUE; turn =0; while ( flag[0 ] && turn ==0); CRITICAL SECTION flag[ 1 ] = FALSE; REMAINDER SECTION } while (TRUE); P0P0P0P0 P1P1P1P1 補充

18. 6.18Operating System Concepts 6.4 Synchronization Hardware Many systems provide hardware support for critical section code All solutions below based on idea of locking Protecting critical regions via locks Uni-processors – could disable interrupts Currently running code would execute without preemption Disable interrupts is generally too inefficient on multiprocessor systems Operating systems using this not broadly scalable p.263 X

19. 6.19Operating System Concepts Special atomic hardware instructions Modern machines provide special atomic hardware instructions Atomically = one uninterruptable unit Either test memory word and set value Or swap contents of two memory words p.263

20. 6.20Operating System Concepts TestAndndSet Instruction Test and modify the content of a word atomically Definition: boolean TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv: } p.264

21. 6.21Operating System Concepts Solution using TestAndSet Shared boolean variable lock., initialized to false. Solution: do { while ( TestAndSet (&lock )) ; /* do nothing // critical section lock = FALSE; // remainder section } while ( TRUE); p.264

22. 6.22Operating System Concepts Solution using TestAndSet t1t2t3t4 P 1 requesting P 0 requestingP 1 exiting P 1 requesting TestandSetFalseTrue False LockTrue FalseTrue CRITICAL SECTION P 1 EnteringP 0 Waiting P 1 Entering => Mutual Exclusion P 0 Waiting P 1 may be Entering P 0 Waiting => X progress X Bounded waiting do { while ( TestAndSet (&lock )) ; /* do nothing // critical section lock = FALSE; // remainder section } while ( TRUE); P0P0P0P0 do { while ( TestAndSet (&lock )) ; /* do nothing // critical section lock = FALSE; // remainder section } while ( TRUE); P1P1P1P1 補充

23. 6.23Operating System Concepts compare_and_swap Instruction Definition: int compare and swap(int *value, int expected, int new value) { int temp = *value; if (*value == expected) *value = new value; return temp; } p.264

24. 6.24Operating System Concepts Solution using compare_and_swap Shared Boolean variable lock initialized to FALSE Solution: do { while (compare and swap(&lock, 0, 1) != 0) ; /* do nothing */ /* critical section */ lock = 0; /* remainder section */ } while (true); p.265

25. 6.25Operating System Concepts Solution using compare_and_swap t1t2t3t4 P 1 requestingP 0 requestingP 1 exitingP 1 requesting lock0 -> 111 -> 00 -> 1 CRITICAL SECTION P 1 EnteringP 0 Waiting P 1 Entering => Mutual Exclusion P 0 WaitingP 1 may be Entering P 0 Waiting => X progress X Bounded waiting do { while (compare and swap(&lock, 0, 1) != 0) ; /* do nothing */ /* critical section */ lock = 0; /* remainder section */ } while (true); P0P0P0P0 do { while (compare and swap(&lock, 0, 1) != 0) ; /* do nothing */ /* critical section */ lock = 0; /* remainder section */ } while (true); P1P1P1P1 補充

26. 6.26Operating System Concepts Satisfies three requirements Shared variable: boolean waiting[n], lock; (initially all false) Process Pi do { 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 } while(1) Complicated for application programmer p.265

27. 6.27Operating System Concepts Satisfies three requirements t1t2t3t4 P 1 requestingP 0 requestingP 1 exitingP 1 requesting waiting[ 0 ] False->TrueFalse waiting[ 1 ] -> True -> False FalseTrue KeyT-> F-> T T -> T LockTrue True ->FalseTrue j0 CRITICAL SECTION P 1 EnteringP 0 Waiting P 1 Entering => Mutual Exclusion P 0 Entering => Progress P 1 Waiting =>Bounded waiting 補充

28. 6.28Operating System Concepts 6.5 Mutex Locks Previous solutions are complicated and generally inaccessible to application programmers OS designers build software tools to solve critical section problem Simplest is mutex lock p.266

29. 6.29Operating System Concepts Product critical regions with it by first acquire() a lock then release() it do { acquire lock critical section release lock remainder section } while (true); acquire() and release() p.266

30. 6.30Operating System Concepts Calls to acquire() and release() must be atomic Usually implemented via hardware atomic instructions Boolean variable available indicating if lock is available or not acquire() { while (!available) ; /* busy wait */ available = false; } release() { available = true; } acquire() and release() p.267

31. 6.31Operating System Concepts Spinlock But this solution requires busy waiting This lock therefore called a spinlock Disadvantage: busy waiting wastes CPU cycles(Signal-Processor) Advantage: No context switch is required when a process spinlock (Multi-Processor) p.267 P1P1 P2P2 P3P3 P4P4 P1P1 P2P2 P3P3 P4P4 P1P1 P2P2 P3P3 P4P4 busy waiting P 3 busy waitingP 4 busy waiting P 1 RunningP 2 busy waiting

32. 6.32Operating System Concepts 6.6 Semaphore Synchronization tool Less complicated 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) ; // busy wait S--; } signal (S) { S++; } p.267

33. 6.33Operating System Concepts 6.6.1 Usage 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 Then a mutex locks p.268

34. 6.34Operating System Concepts Critical-section of n processes Binary semaphores to deal with the critical-section problem for multiple processes Mutual-exclusion implement with semaphores Shared variables: semaphore mutex =1; Process P 1 Process P 2 p.268

35. 6.35Operating System Concepts Control Resource Counting semaphores can be to control access to a given resource consisting of a finite number of instances. The semaphore is initialized to the number of resources available. Each process that wishes to use a resource performs a wait( ) When a process releases a resources, it performs a signal( ) p.268

36. 6.36Operating System Concepts Synchronization Problems Can solve various synchronization problems Consider P 1 and P 2 that require S 1 to happen before S 2 S1S1 S2S2 S1S1 S2S2 P1P1 P1P1 P1P1 P1P1 P2P2 P2P2 P2P2 p.268

37. 6.37Operating System Concepts 6.6. 2 Semaphore Implementation with no Busy waiting 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. Each entry in a waiting queue has two data items: value (of type integer) pointer to next record in the list p.269

38. 6.38Operating System Concepts Semaphore Implementation with no Busy waiting (Cont.) Implementation of semaphores Implementation of wait: Implementation of signal: wait (S) { while S <= 0 ; // no-op S--; } signal (S) { S++; } p.269

39. 6.39Operating System Concepts Interrupt for Critical-Section wait( ), signal( ) => share Semaphore S => critical- section problem A single-processor environment: We can inhibiting interrupts during the time the wait( ) and signal( ) operations are executing A multiprocessor environment: disabling interrupts on every processor can be difficult task and furthermore can seriously diminish performance SMP systems must provide spinlocks to ensure that wait( ) and signal( ) preformed atomically We have limited busy waiting to the critical sections of the wait( ) and signal( ), and these sections are short. p.270

40. 6.40Operating System Concepts 6.6.3 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. (1) S=S-1=0(2)Q=Q-1=0 p.271

41. 6.41Operating System Concepts 6.6.4 Priority Inversion Scheduling problem when lower-priority process holds a lock needed by higher- priority process Solved via priority-inheritance protocol p.271

42. 6.42Operating System Concepts 6.7 Classical Problems of Synchronization Bounded-Buffer Problem Readers and Writers Problem Dining-Philosophers Problem p.273

43. 6.43Operating System Concepts 6.7.1 Bounded-Buffer Problem n buffers, each can hold one item Semaphore mutex initialized to the value 1 Semaphore empty initialized to the value n Semaphore full initialized to the value 0 p.273

44. 6.44Operating System Concepts Bounded-Buffer Problem t1t2t3t4t5 C requestingP requestingP exitingC WakeupC exiting full =000100 empty=nnn-1 n mutex =110101 bufferC WaitingP EnteringC Wakeup p.273

45. 6.45Operating System Concepts 6.7.2 Readers-Writers Problem A database is to be shared among several concurrent processes Readers – only read the database; 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. p.274

46. 6.46Operating System Concepts Readers-Writers Problem Reader first: No reader will be kept waiting unless a writer has already obtained permission to use the shared object Writer first: once a writer is ready, that writer performs its write as soon as possible the solution to either problem may result in starvation p.274

47. 6.47Operating System Concepts Starvation–free Solution to the Readers-Writers Problem Reader first – Shared Data Semaphore rw_mutex initialized to 1. Semaphore mutex initialized to 1. Integer read_count initialized to 0. do { wait(mutex); read_count++; if (read_count == 1) wait(rw_mutex); signal(mutex);... /* reading is performed */... wait(mutex); read_count--; if (read_count == 0) signal(rw_mutex); signal(mutex); } while (true); Readers-Writers Problem p.275 do { wait(rw_mutex);... /* writing is performed */... signal(rw_mutex); } while (true);

48. 6.48Operating System Concepts Reader-Writer Locks some system provide reader-writer locks read mode : a process only wishes to read shared data  Multiple processes are permitted on concurrently write mode : a process wishing to modify the shared data  Only one process may acquire the lock most useful in following situation : In applications where it is easy to identify which processes only read shared data and which processes only write shared data In applications that have more readers than writers.  reader-writer locks generally require more overhead to establish than semaphores or mutual exclusion locks p.276

49. 6.49Operating System Concepts 6.7.3 Dining-Philosophers Problem Shared data Bowl of rice (data set) Semaphore chopstick [5] initialized to 1 p.276

50. 6.50Operating System Concepts Dining-Philosophers Problem The structure of Philosopher i: Could create a deadlock p.277

51. 6.51Operating System Concepts Some Solution Allow at most four philosophers to be sitting simultaneously at the table Allow a philosopher to pick up her chopsticks only if both chopsticks are available to do this she must pick then up in a critical section Use an asymmetric solution; an odd philosopher picks up her left chopstick and then her right chopstick an even philosopher pick up her right chopstick and then her left chopstick p.277

52. 6.52Operating System Concepts 6.8 Monitors Uncorrected use of semaphore operations: a process interchanges the order in which the wait( ) and signal( ) operations on the semaphore mutex are executed  signal (mutex) …. wait (mutex) – violating the mutual-exclusion requirement a process replace signal( ) with wait( )  wait (mutex) … wait (mutex) – in this case, a deadlock will occur Omitting of wait (mutex) or signal (mutex) (or both)  either mutual-exclusion is violated or a deadlock will occur Monitor : high-level language constructs

53. 6.53Operating System Concepts Monitors A high-level abstraction that provides a convenient and effective mechanism for process synchronization Only one process may be active within the monitor at a time monitor monitor-name { // shared variable declarations procedure P1 (…) { …. } … procedure Pn (…) {……} Initialization code ( ….) { … } … }

54. 6.54Operating System Concepts Schematic view of a Monitor

55. 6.55Operating System Concepts Condition Variables The monitor construct ensures that only one process at a time can be active within the monitor The monitor is not sufficiently powerful for modeling some synchronization schemes. Additional synchronization mechanism (condition construct)  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 ( ). If no process is suspended, then the signal( ) operation has no effect.

56. 6.56Operating System Concepts Monitor with Condition Variables Monitor with Condition Variables

57. 6.57Operating System Concepts Exclusive execution Signal and wait P either waits until Q leaves the monitor or waits for another condition. Signal and continue Q either waits until P leaves the monitor or waits for another condition. Concurrent Pascal When thread P executes the signal operation. it immediately leaves the monitor

58. 6.58Operating System Concepts Solution to Dining Philosophers monitor DP { enum { THINKING; HUNGRY, EATING) state [5] ; condition self [5]; 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); test((i + 1) % 5); } 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; }

59. 6.59Operating System Concepts Dining-Philosopher using Monitor Philosopher i must invoke the operations pickup(i) and putdown(i) in the following sequence:

60. 6.60Operating System Concepts Implementing a Monitor Using Semaphores The monitor mechanism use semaphores semaphore mutex =1, next =0; integer variable next_count =0; The monitor construct ensures that only one process at a time can be active within the monitor wait(mutex)... body of F... if (next_count > 0) signal(next); else signal(mutex);

61. 6.61Operating System Concepts Condition variable implement For each condition x, we introduce a semaphore semaphore x_sem =0; integer variable x_count =0; The x.wait( ) and x.signal( ) are implemented as x.wait( ) x_count ++; if (next_count > 0) signal(next); else signal(mutex); wait(x_sem); x_count --; x.signal( ) if (x_count > 0) { next_count ++; signal(x_sem); wait(next); next_count --; }

62. 6.62Operating System Concepts Resuming Processes within a Monitor When x.signal( ) is executed, which suspended processes should be resumed next? FCFS ordering Conditional-wait  x.wait(c), where c is an integer value (priority number)  the smallest associated priority number is resumed next

63. 6.63Operating System Concepts Allocate a single resource monitor ResourceAllocator { boolean busy; condition x; void acquire(int time) { if (busy) x.wait(time); busy = TRUE; } void release( ) { busy = FALSE; x.signal( ); } initialization code( ) { busy = FALSE; } R.acquire(t);... access the resource;... R.release( );

64. 6.64Operating System Concepts Monitor cannot guarantee A process might access a resource without first gaining access permission to the resource. A process might never release a resource once it has been granted access the resource. A process might attempt to release a resource that it never requested. A process might request the same resource twice (without first releasing the resource)

65. 6.65Operating System Concepts 6.9 Synchronization Examples Solaris Windows XP Linux Pthreads

66. 6.66Operating System Concepts Solaris Synchronization Implements a variety of locks to support multitasking, multithreading (including real-time threads), and multiprocessing adaptive mutexes for efficiency when protecting data from short code segments condition variables, readers-writers locks, semaphores when longer sections of code need access to data turnstiles to order the list of threads waiting to acquire either an adaptive mutex or reader-writer lock

67. 6.67Operating System Concepts Adaptive mutex Adaptive mutex starts as a standard semaphore implemented as a spinlock Multiprocessor system if the lock is held by a thread that is currently running on another CPU ➡ the thread spinlock if the thread holding the lock is not currently in run state ➡ the thread blocks Single-processor system thread always block rather than spin protect data that are accessed by short code segment

68. 6.68Operating System Concepts Condition Variable condition variable and semaphore are used for these longer code segments If the desired lock is already held, the thread issues a wait and sleeps When a thread frees the lock, it issues a signal to the next sleeping thread in the queue The extra cost of putting a thread to sleep and waking it is less than the cost of waiting in a spinlock

69. 6.69Operating System Concepts Reader-writer locks Reader-writer locks are used to protect data that are accessed frequently but are usually accessed in a read-only manner Reader-writer locks are more efficient than semaphore Multiple threads can read data concurrently in reader-writer locks semaphores always serialize access to the data Reader-writer locks are relatively expensive to implement, so they are used on long section of code

70. 6.70Operating System Concepts Turnstile A turnstile is a queue structure containing thread blocked on a lock turnstile order the list of threads waiting to acquire either adaptive mutex or reader-writer lock when the lock is released, the kernel selects a thread from the turnstile as the next owner of the lock Solaris gives each kernel thread its own turnstile rather than associating a turnstile with each synchronized object. Turnstiles are organized according to a priorityinheritance protocol

71. 6.71Operating System Concepts 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

72. 6.72Operating System Concepts Linux Synchronization Linux: disables interrupts to implement short critical sections Linux provides: semaphores spin locks

73. 6.73Operating System Concepts Pthreads Synchronization Pthreads API is OS-independent It provides: mutex locks condition variables Non-portable extensions include: read-write locks spin locks

74. End of Chapter 6