Chapter 5: Process Synchronization

Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Alternative Approaches 5.2 Silberschatz, Galvin and Gagne 2013 1

Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Alternative Approaches 5.3 Silberschatz, Galvin and Gagne 2013 5.5 Silberschatz, Galvin and Gagne 2013 2

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 5.6 Silberschatz, Galvin and Gagne 2013 An example: the early P-C solution item buffer[buffer_size]; int in = 0; int out = 0; Producer item next_produced; while (true) { /* produce an item in next_produced */ while (((in + 1) % BUFFER_SIZE) == out) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; item next_consumed; while (true) { Consumer while (in == out) ; /* do nothing */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; /* consume the item in next_consumed */ 5.7 Silberschatz, Galvin and Gagne 2013 3

An example: the early P-C solution (con t) Suppose that we wanted to provide a solution to the consumer-producer problem that fills all the buffers. 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.8 Silberschatz, Galvin and Gagne 2013 Producer while (true) { /* produce an item in next produced */ while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; counter++; 5.9 Silberschatz, Galvin and Gagne 2013 4

Consumer while (true) { while (counter == 0) ; /* do nothing */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; /* consume the item in next consumed */ 5.10 Silberschatz, Galvin and Gagne 2013 Race Condition counter++ could be implemented as register1 = counter register1 = register1 + 1 counter = register1 counter-- could be implemented as register2 = counter register2 = register2-1 counter = register2 5.11 Silberschatz, Galvin and Gagne 2013 5

Race Condition Consider this execution interleaving with count = 5 initially: producer execute counter++ S0: register1 = counter {register1 = 5 S1: register1 = register1 + 1 {register1 = 6 S2: consumer execute S3: consumer execute S4: counter = register1 {counter = 6 S5: consumer execute consumer execute counter-- S0: producer execute S1: producer execute S2: register2 = counter {register2 = 5 S3: register2 = register2 1 {register2 = 4 S4: producer execute S5: counter = register2 {counter = 4 5.12 Silberschatz, Galvin and Gagne 2013 Critical Section General structure of process P i 5.13 Silberschatz, Galvin and Gagne 2013 6

Producer: where is the Critical-Section? while (true) { /* produce an item in next produced */ while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = next_produced; entry code in = (in + 1) % BUFFER_SIZE; counter++; exit code Will reading a variable cause race condition? 5.14 Silberschatz, Galvin and Gagne 2013 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 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 5.15 Silberschatz, Galvin and Gagne 2013 7

Solution to Critical-Section Problem 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 Assume that each process executes at a nonzero speed No assumption concerning relative speed of the n processes 5.16 Silberschatz, Galvin and Gagne 2013 Critical-Section Handling in OS Two approaches depending on if kernel is preemptive or non-preemptive Preemptive allows preemption of process when running in kernel mode Non-preemptive runs until exits kernel mode, blocks, or voluntarily yields CPU Essentially free of race conditions in kernel mode 5.17 Silberschatz, Galvin and Gagne 2013 8

Exercise In the counter-based implementation of producer-consumer problem, could buffer produce race condition? How so? Show analysis. item next_produced; while (true) { /* produce an item in next produced */ while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; counter++; item buffer[buffer_size]; int in = 0; int out = 0; int counter = 0; Producer item next_consumed; while (true) { while (counter == 0) ; /* do nothing */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; /* consume the item in next consumed */ Consumer What about variables in and out? 5.18 Silberschatz, Galvin and Gagne 2013 Could the code produce race condition? item buffer[buffer_size]; int in = 0; int out = 0; Producer item next_produced; while (true) { /* produce an item in next produced */ while (((in + 1) % BUFFER_SIZE) == out) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; item next_consumed; while (true) { Consumer while (in == out) ; /* do nothing */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; /* consume the item in next consumed */ 5.19 Silberschatz, Galvin and Gagne 2013 9

5.20 Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Alternative Approaches a Because good algorithmic of the way description modern computer of solving architectures the criticalsection perform problem basic machine-language and illustrates some instructions, of the complexities such as involved load and in store, designing there software no guarantees that addresses that the requirements Peterson s solution of mutual will exclusion, work correctly progress, on such and bounded waiting. architectures. 5.21 Silberschatz, Galvin and Gagne 2013 10

First Try: Algorithm for P 1 and P 2 P1: do { while (turn == 2); critical section turn = 2; remainder section while (true); 5.22 Silberschatz, Galvin and Gagne 2013 Second Try: Algorithm for P 1 and P 2 Boolean f1,f2; // true: process is ready to enter CS! P1: do { f1 = true; while (f2); // do nothing critical section f1 = false; remainder section while (true); P2: do { f2 = true; while (f1); // do nothing critical section f2 = false; remainder section while (true); 5.23 Silberschatz, Galvin and Gagne 2013 11

Third Try: Algorithm for P 1 and P 2 Boolean f1,f2; // true: process is ready to enter CS! int turn; //turn: whose turn it is to enter the CS; P1: do { f1 = true; turn = 2; while (f2 && turn = = 2); // do nothing critical section f1 = false; remainder section while (true); P2: do { f2 = true; turn = 1; while (f1 && turn = = 1); // do nothing critical section f2 = false; remainder section while (true); 5.24 Silberschatz, Galvin and Gagne 2013 Peterson s Solution Good algorithmic description of solving the problem Two process solution Assume that the load and store machine-language 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! 5.25 Silberschatz, Galvin and Gagne 2013 12

Algorithm for Process P i int turn; Boolean flag[2] do { flag[i] = true; turn = j; while (flag[j] && turn = = j); critical section flag[i] = false; while (true); // Suppose i = 0, j = 1; // Code similar for Pj. remainder section turn: whose turn it is to enter the CS; flag[i] = true: process Pi is ready! 5.26 Silberschatz, Galvin and Gagne 2013 Peterson s Solution (Cont.) Provable that the three CS requirements are met: 1. Mutual exclusion is preserved P i enters CS only if: either flag[j] = false or turn = i 2. Progress requirement is satisfied 3. Bounded-waiting requirement is met 5.27 Silberschatz, Galvin and Gagne 2013 13

Example 1 Initial : turn = 0 ; flag[0] = FALSE ; flag[1] = FALSE Process 0 Process 1 flag[0] = TRUE turn = 1 check (flag[1] == TRUE and turn == 1) - Condition is false because flag[1] = FALSE - Since condition is false, no waiting in while loop - Enter the critical section - Process 0 happens to lose the processor - Process 0 resumes and continues until it finishes in the critical section - Leave critical section flag[0] = FALSE Start executing the remainder - Process 0 happens to lose the processor flag[1] = TRUE turn = 0 check (flag[0] == TRUE and turn == 0) - Since condition is true, it keeps busy waiting until it loses the processor check (flag[0] == TRUE and turn == 0) - This condition fails because flag[0] == FALSE - No more busy waiting - Enter the critical section 5.28 Silberschatz, Galvin and Gagne 2013 Example 2 Initial : turn = 0 ; flag[0] = FALSE ; flag[1] = FALSE Process 0 Process 1 flag[0] = TRUE turn = 1 - Process 0 happens to lose the processor check (flag[1] == TRUE and turn == 1) -This condition is false because turn ==0 - Process 0 no waiting in loop - Enters critical section (try to work out the remaining, similar to example 1) flag[1] = TRUE turn = 0 check (flag[0] == TRUE and turn == 0) - Since condition is true, it keeps busy waiting until it loses the processor 5.29 Silberschatz, Galvin and Gagne 2013 14

Example 3 Initial : turn = 0 ; flag[0] = FALSE ; flag[1] = FALSE Process 0 Process 1 flag[0] = TRUE Process 0 happens to lose the processor turn = 1 check (flag[1] == TRUE and turn == 1) - Condition is true so it busy waits until it loses the processor flag[1] = TRUE turn = 0 check (flag[0] == TRUE and turn == 0) - Since condition is true, it keeps busy waiting until it loses the processor check (flag[0] == TRUE and turn == 0) - This condition fails because turn== 1 - So no busy waiting, it enters the critical section 5.30 Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Alternative Approaches 5.31 Silberschatz, Galvin and Gagne 2013 15

Synchronization Hardware (I) Many systems provide hardware support for implementing the critical section code. All solutions below based on idea of locking Protecting critical regions via locks do { acquire lock critical section release lock remainder section while (TRUE); Check LOCK, If locked, wait till unlock; (!) Lock the LOCK; (enter CS) Unlock the LOCK; (exit CS) 5.32 Silberschatz, Galvin and Gagne 2013 Synchronization Hardware (II) 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-interruptible Either test memory word and set value Or swap contents of two memory words 5.34 Silberschatz, Galvin and Gagne 2013 16

test_and_set Instruction Definition: boolean test_and_set (boolean *target) { boolean rv = *target; *target = TRUE; return rv: 1. Executed atomically 2. Returns the original value of passed parameter 3. Set the new value of passed parameter to TRUE. 5.35 Silberschatz, Galvin and Gagne 2013 Solution using test_and_set() Shared Boolean variable lock, initialized to FALSE Solution: do { while (test_and_set(&lock)) ; /* do nothing */ /* critical section */ Why this is good? lock = false; /* remainder section */ while (true); 5.36 Silberschatz, Galvin and Gagne 2013 17

Analysis the two cases 1. Mutual Exclusion - 2. Progress - 3. Bounded Waiting - 5.37 Silberschatz, Galvin and Gagne 2013 Solution using test_and_set() Shared Boolean variable lock, initialized to FALSE Solution: do { while (test_and_set(&lock)) ; /* do nothing */ /* critical section */ lock = false; /* remainder section */ while (true); 5.38 Silberschatz, Galvin and Gagne 2013 18

Example, Analyze test_and_set() target = FALSE Process 1 Process 2 Want to set target to TRUE Target is changed to TRUE Result comes back as FALSE, so no busy-waiting In critical section Want to set target to TRUE It receives the result TRUE busy-waits as long as Process 1 is in the critical section Leaves critical section Sets target to FALSE Mutual Exclusion, Progress, Bounded Waiting 5.39 Silberschatz, Galvin and Gagne 2013 Bounded-waiting Mutual Exclusion with test_and_set Order the processes, remember which are waiting. Boolean waiting[n]; Boolean lock; do { Is itself waiting & locked? If so, busy-waiting; (unlocked); set itself not waiting; /* critical section */ Find next waiting process; if found, Make it not waiting; Or, unlock /* remainder section */ while (true); 5.40 Silberschatz, Galvin and Gagne 2013 19

Bounded-waiting Mutual Exclusion with test_and_set do { waiting[i] = true; key = true; while (waiting[i] && key) key = test_and_set(&lock); waiting[i] = false; /* critical section */ j = (i + 1) % n; while ((j!= i) &&!waiting[j]) j = (j + 1) % n; if (j == i) else lock = false; waiting[j] = false; /* remainder section */ while (true); Boolean waiting[n]; Boolean lock; Note: key is local; 2 conds for entering CS Find next waiting process, Still in CS No waiting process, exit by lock = F Find a waiting, Exit by set it to not waiting, But lock is T 5.41 Silberschatz, Galvin and Gagne 2013 Analysis the solution 1. Mutual Exclusion - 2. Progress - 3. Bounded Waiting - 5.42 Silberschatz, Galvin and Gagne 2013 20

5.43 Silberschatz, Galvin and Gagne 2013 Recap: Check LOCK, If locked, wait till unlock; (!) Lock the LOCK; (enter CS) CS Unlock the LOCK; (exit CS) Synchronization Hardware do { while (test_and_set(&lock)) ; /* do nothing */ /* critical section */ lock = false; /* remainder section */ while (true); Solutions meet three requirements: Mutual Exclusion, Progress, Bounded Waiting 5.44 Silberschatz, Galvin and Gagne 2013 21

Definition: compare_and_swap Instruction int compare_and_swap(int *value, int expected, int new_value) { int temp = *value; if (*value == expected) *value = new_value; return temp; 1. Executed atomically 2. Returns the original value of passed parameter value 3. Set the variable value the value of the passed parameter new_value but only if value == expected. That is, the swap takes place only under this condition. 5.45 Silberschatz, Galvin and Gagne 2013 Solution using compare_and_swap Shared integer lock initialized to 0 (meaning, not locked); Solution: do { while (compare_and_swap(&lock, 0, 1)!= 0) ; /* do nothing */ /* critical section */ lock = 0; /* remainder section */ while (true); 5.46 Silberschatz, Galvin and Gagne 2013 22

5.14 : use compare_and_swap to mutual exclusion that satisfies the bounded-waiting requirement. Study the solutions in 5.8 and 5.9; Prove that the three requirements are satisfied! Software solution 5.47 Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Alternative Approaches 5.49 Silberschatz, Galvin and Gagne 2013 23

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 Boolean variable indicating if lock is available or not Protect a critical section by first acquire() a lock then release() the lock Calls to acquire() and release() must be atomic Usually implemented via hardware atomic instructions Note: this solution requires busy waiting This lock therefore called a spinlock 5.52 Silberschatz, Galvin and Gagne 2013 acquire() and release() let available be the mutex. acquire() { while (!available) ; /* busy wait */ available = false;; release() { available = true; 5.53 Silberschatz, Galvin and Gagne 2013 24

Producer: Let A be a mutex, initialized to T; while (true) { /* produce an item in next produced */ while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; acquire(a); counter++; release(a); exit code entry code 5.54 Silberschatz, Galvin and Gagne 2013 Example 5.15 Consider how to implement a mutex lock using an atomic hardware instruction. Assume that the following structure defining the mutex lock is available: typedef struct { lock; int available; where (available == 0) indicates the lock is available; a value of 1 indicates the lock is unavailable. Using this struct, illustrate how the following functions may be implemented using the test_and_set() and compare_and_swap() instructions. void acquire(lock *mutex) void release(lock *mutex) Be sure to include any initialization that may be necessary. 5.56 Silberschatz, Galvin and Gagne 2013 25

Example(cont d 1) // initialization mutex->available = 0; // acquire using test_and_set() void acquire(lock *mutex) { while (test_and_set(&mutex->available)!= 0) ; return; void release(lock *mutex) { mutex->available = 0; return; 5.57 Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Alternative Approaches 5.60 Silberschatz, Galvin and Gagne 2013 26

Semaphore More sophisticated ways (than Mutex locks) for synchronizing process activities. Examples Can solve various synchronization problems Semaphore S integer variable Can only be accessed via two indivisible (atomic) operations wait() and signal() Originally called P() and V() 5.61 Silberschatz, Galvin and Gagne 2013 Semaphore Definition of the wait() operation wait(s) { while (S <= 0) ; // busy wait S--; Definition of the signal() operation signal(s) { S++; 5.62 Silberschatz, Galvin and Gagne 2013 27

Semaphore Usage I Binary semaphore integer value can range only between 0 and 1 Same as a mutex lock The producer with counter: Create a semaphore W initialized to 1; while (true) { /* produce an item in next produced */ while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; wait(w); counter++; signal(w); 5.63 Silberschatz, Galvin and Gagne 2013 Semaphore Usage II Counting semaphore integer value can range over an unrestricted domain Semaphore empty initialized to the value n Counting the number of empty buffers do { /* produce an item in next_produced */ wait(empty); // More to add later /* add next produced to the buffer */ // More to add later; signal(full); while (true); Can implement a counting semaphore S as a binary semaphore 5.64 Silberschatz, Galvin and Gagne 2013 28

Semaphore Usage III Other types of synchronization problems Generate an order: Consider P 1 and P 2 that require S 1 to happen before S 2: Create a semaphore synch initialized to 0 P1: S 1 ; signal(synch); P2: wait(synch); S 2 ; 5.65 Silberschatz, Galvin and Gagne 2013 Semaphore Usage III (example) Semaphore empty initialized to the value n Counting the number of empty buffers Consumer has waited on full, counting on filled buffers, initialzed to 0 do { /* produce an item in next_produced */ wait(empty); // More to add later /* add next produced to the buffer */ // More to add later; signal(full); while (true); Can implement a counting semaphore S as a binary semaphore 5.66 Silberschatz, Galvin and Gagne 2013 29

Semaphore Implementation (1) Three issues to consider: Critical section problem for wait() & signal() on the same semaphore; Busy-waiting; Bounded waiting; 5.67 Silberschatz, Galvin and Gagne 2013 Semaphore Implementation (2) Critical section problem No two processes can execute the wait() and signal() on the same semaphore at the same time Definition of the wait() operation wait(s) { while (S <= 0) ; // busy wait S--; Definition of the signal() operation signal(s) { S++; 5.68 Silberschatz, Galvin and Gagne 2013 30

Semaphore Implementation (2.5) Critical section problem Thus, the implementation of semaphore, becomes the critical section problem where the wait and signal code are placed in the critical section Could now have busy waiting in critical section implementation But implementation code is short Little busy waiting if critical section rarely occupied Note: This is different from using semaphore for critical section of an application -- the applications may spend lots of time in critical sections and therefore busy waiting not a good solution 5.69 Silberschatz, Galvin and Gagne 2013 Semaphore Implementation with no Busy waiting With each semaphore there is an associated waiting queue Each entry in a waiting queue has two data items: value (of type integer) pointer to next record in the list 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 typedef struct{ int value; struct process *list; semaphore; 5.70 Silberschatz, Galvin and Gagne 2013 31

Implementation with no Busy waiting (Cont.) wait(semaphore *S) { S->value--; if (S->value < 0) { add this process to S->list; block(); signal(semaphore *S) { S->value++; if (S->value <= 0) { remove a process P from S->list; wakeup(p); 5.71 Silberschatz, Galvin and Gagne 2013 Example Binary semaphore, initiated to value = 1 Process 1 Process 2 Start the wait routine S.value = 0 finish the wait routine Start the wait routine S.value = -1 If S.value < 0 then add P2 to queue Suspend P2 5.72 Silberschatz, Galvin and Gagne 2013 32

The Requirements 1. Mutual Exclusion - 2. Progress - 3. Bounded Waiting - 5.73 Silberschatz, Galvin and Gagne 2013 An example 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); 5.75 Silberschatz, Galvin and Gagne 2013 33

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 Starvation indefinite blocking A process may never be removed from the semaphore queue in which it is suspended Two cases: Last-in first-out queue of semaphore implementation Locks on kernel data structure and priority based scheduling Priority Inversion Scheduling problem when lower-priority process holds a lock needed by higher-priority process Solved via priority-inheritance protocol 5.76 Silberschatz, Galvin and Gagne 2013 Summary: Mutex and Semaphore Usage Mutex Boolean variable indicating if lock is available or not acquire()and release() Semaphore S integer variable wait() and signal() Binary semaphore integer value can range only between 0 and 1 Same as a mutex lock Counting semaphore integer value can range over an unrestricted domain Preserve an order of execution sequences Can solve various synchronization problems Solution requirements: Mutual Exclusion, Progress, Bounded Waiting Deadlock and Starvation 5.77 Silberschatz, Galvin and Gagne 2013 34

Home Reading: know Mutex and Semaphore well, get ready to use them to solve problems on Friday. 5.78 Silberschatz, Galvin and Gagne 2013 5.79 Silberschatz, Galvin and Gagne 2013 35

Recap: Mutex and Semaphore Usage Mutex Boolean variable indicating if lock is available or not acquire()and release() Semaphore S integer variable wait() and signal() Binary semaphore integer value can range only between 0 and 1 Same as a mutex lock Counting semaphore integer value can range over an unrestricted domain Preserve an order of execution sequences Can solve various synchronization problems Solution requirements: Mutual Exclusion, Progress, Bounded Waiting Deadlock and Starvation 5.80 Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Alternative Approaches 5.81 Silberschatz, Galvin and Gagne 2013 36

Classical Problems of Synchronization Classical problems used to test newly-proposed synchronization schemes Bounded-Buffer Problem Readers and Writers Problem Dining-Philosophers Problem 5.82 Silberschatz, Galvin and Gagne 2013 item next_produced; while (true) { /* produce an item in next produced */ How do Producer and Consumer synch? item buffer[buffer_size]; int in = 0; int out = 0; int counter = 0; Producer while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; counter++; item next_consumed; while (true) { while (counter == 0) ; /* do nothing */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--; Consumer Synch when buffer is full or empty. counting the numbers Synch when sheared data is accessed /* consume the item in next consumed */ 5.83 Silberschatz, Galvin and Gagne 2013 37

Bounded-Buffer Problem n buffers, each can hold one item Semaphore mutex initialized to the value 1 Semaphore full initialized to the value 0 Counting the number of buffers holding an item Semaphore empty initialized to the value n Counting the number of empty buffers 5.86 Silberschatz, Galvin and Gagne 2013 Bounded Buffer Problem (Cont.) The structure of the Producer process do {... /* produce an item in next_produced */... wait(empty); wait(mutex);... /* add next produced to the buffer */... signal(mutex); signal(full);... while (true); 5.87 Silberschatz, Galvin and Gagne 2013 38

Bounded Buffer Problem (Cont.) The structure of the Consumer process Do { wait(full); wait(mutex);... /* remove an item from buffer to next_consumed */... signal(mutex); signal(empty);... /* consume the item in next consumed */... while (true); 5.88 Silberschatz, Galvin and Gagne 2013 Producer - produce an item in nextp wait(empty); - Lose CPU wait(mutex); - add nextp to the buffer signal(mutex); signal(full); Evaluate Example mutex = 1; empty = n; full = 0; Consumer wait(full); - cannot proceed because no items in buffer - produce an item in nextp wait(empty); wait(mutex); - add nextp to the buffer signal(mutex); - Lose CPU - wait(full) is now successful because one item added to buffer 5.89 Silberschatz, Galvin and Gagne 2013 39

http://www.doc.ic.ac.uk/~jnm/book/book_applets/readerswriters.html http://williamstallings.com/os/animation/animations.html 5.90 Silberschatz, Galvin and Gagne 2013 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 Several variations of how readers and writers are considered all involve some form of priorities First variation no reader kept waiting unless writer has permission to use shared object Second variation once writer is ready, it performs the write ASAP Both may have starvation leading to even more variations 5.91 Silberschatz, Galvin and Gagne 2013 40

Readers-Writers Problem First variation no reader kept waiting unless writer has permission to use shared object. When finding a writer is waiting (has readers already), new reader should not wait How to implement the logic of the problem? Shared Data set: Order readers and writers: If first reader, block W or be blocked by accessing W; // for latter case, till W done //counting readers; Semaphore rw_mutex initialized to 1 // W be blocked when Readers accessing //multiple W synched by rw_mutex; Integer read_count initialized to 0 Semaphore mutex initialized to 1 // synch multiple Readers If last reader, unblock W. 5.93 Silberschatz, Galvin and Gagne 2013 Readers-Writers Problem (Cont.) The structure of a Writer process do { wait(rw_mutex);... /* writing is performed */... signal(rw_mutex); while (true); 5.94 Silberschatz, Galvin and Gagne 2013 41

Readers-Writers Problem (Cont.) The structure of a Reader process 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); 5.95 Silberschatz, Galvin and Gagne 2013 Evaluation, etc First variation of Readers-Writers problem Mutual Exclusion, Progress, Bounded Waiting Second variation once writer is ready, it performs the write ASAP When one or more writers is waiting to access the file, newly arriving readers are blocked When an active writer departs, waiting readers are unblocked in preference to unblocking another writer Encourage you to work out a solution. Semaphore Implementation 67-72 5.96 Silberschatz, Galvin and Gagne 2013 42

Assignment 2 Use a loop and sleep with a random number Use ONE makefile for all the three problems. Use comment spot in BBL submission to let TA know how to compile your code. 5.97 Silberschatz, Galvin and Gagne 2013 5.98 Silberschatz, Galvin and Gagne 2013 43

Recap: Mutex and Semaphore Usage Mutex Boolean variable indicating if lock is available or not acquire()and release() Semaphore S integer variable wait() and signal() Binary semaphore integer value can range only between 0 and 1 Same as a mutex lock Counting semaphore integer value can range over an unrestricted domain Preserve an order of execution sequences Can solve various synchronization problems Solution requirements: Mutual Exclusion, Progress, Bounded Waiting Deadlock and Starvation 5.104 Silberschatz, Galvin and Gagne 2013 Readers-Writers Problem Variations First variation no reader kept waiting unless writer has permission to use shared object Second variation once writer is ready, it performs the write ASAP Both may have starvation leading to even more variations Problem is solved on some systems by kernel providing reader-writer locks 5.105 Silberschatz, Galvin and Gagne 2013 44

Dining-Philosophers Problem Philosophers spend their lives alternating thinking and eating Don t interact with their neighbors, occasionally try to pick up 2 chopsticks (one at a time) to eat from bowl Need both to eat, then release both when done In the case of 5 philosophers Shared data Bowl of rice (data set) Semaphore chopstick [5] initialized to 1 5.107 Silberschatz, Galvin and Gagne 2013 Dining-Philosophers Problem Algorithm 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); What is the problem with this algorithm? 5.108 Silberschatz, Galvin and Gagne 2013 45

Dining-Philosophers Problem Algorithm (Cont.) Deadlock handling Allow at most 4 philosophers to be sitting simultaneously at the table. Allow a philosopher to pick up the forks only if both are available (picking must be done in a critical section. Use an asymmetric solution -- an oddnumbered philosopher picks up first the left chopstick and then the right chopstick. Evennumbered philosopher picks up first the right chopstick and then the left chopstick. 5.109 Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization Monitors Synchronization Examples Alternative Approaches 5.110 Silberschatz, Galvin and Gagne 2013 46

producer while (true) { /* produce in nextproduced */ wait (mutex); while (count == BUFFER_SIZE) ; buffer [in] = nextproduced; in = (in + 1) % BUFFER_SIZE; count++; signal (mutex); mutex = 1; consumer while (true) { wait(mutex); while (count == 0) ; nextconsumed = buffer[out]; out = (out + 1) %BUFFER_SIZE; count--; signal (mutex); /* consume nextconsumed 5.111 Silberschatz, Galvin and Gagne 2013 Problems with Semaphores Incorrect use of semaphore operations for synchronization. e.g., Mutual exclusion case: signal (sem1). wait (sem1) wait (sem1) wait (sem1) Omitting of wait (sem1) or signal (sem1) (or both) Deadlock and starvation are possible. 5.112 Silberschatz, Galvin and Gagne 2013 47

Monitors A high-level abstraction that provides a convenient and effective mechanism for process synchronization Abstract data type, internal variables only accessible by code within the monitor Only one process may be active within the monitor at a time monitor monitor-name { // shared variable declarations procedure P1 ( ) {. procedure Pn ( ) { Initialization code ( ) { 5.113 Silberschatz, Galvin and Gagne 2013 Schematic view of a Monitor But not powerful enough to model some synchronization schemes 5.114 Silberschatz, Galvin and Gagne 2013 48

Condition Variables condition x, y; Two operations are allowed on a condition variable: x.wait() a process that invokes the operation is suspended until x.signal() x.signal() resumes one of processes (if any) that invoked x.wait() If no x.wait() on the variable, then it has no effect on the variable 5.115 Silberschatz, Galvin and Gagne 2013 Monitor with Condition Variables 5.116 Silberschatz, Galvin and Gagne 2013 49

Monitor Solution to Dining Philosophers monitor DiningPhilosophers { 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); 5.117 Silberschatz, Galvin and Gagne 2013 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; 5.118 Silberschatz, Galvin and Gagne 2013 50

Solution to Dining Philosophers (Cont.) Each philosopher i invokes the operations pickup() and putdown() in the following sequence: DiningPhilosophers.pickup(i); EAT DiningPhilosophers.putdown(i); No deadlock, but starvation is possible 5.119 Silberschatz, Galvin and Gagne 2013 5.32 A file is to be shared among different processes, each of which has a unique number. The file can be accessed simultaneously by several processes, subject to the following constraint: the sum of all unique numbers associated with all the processes currently accessing the file must be less than n. Write a monitor to coordinate access to the file. In process Pi, access_file(n);... finish_access(n); monitor file_access { int curr_sum = 0; int n; condition c; void access_file(int my_num) { while (curr_sum + my_num >= n) c.wait(); curr_sum += my_num; void finish_access(int my_num) { curr_sum -= my_num; c.signal(); 5.120 Silberschatz, Galvin and Gagne 2013 51

Implementation issues 5.124 Silberschatz, Galvin and Gagne 2013 Condition Variables Choices If process P invokes x.signal(), and process Q is suspended in x.wait(), what should happen next? Both Q and P cannot execute in parallel. If Q is resumed, then P must wait Options include Signal and wait P waits until Q either leaves the monitor or it waits for another condition Signal and continue Q waits until P either leaves the monitor or it waits for another condition Both have pros and cons language implementer can decide Monitors implemented in Concurrent Pascal compromise P executing signal immediately leaves the monitor, Q is resumed Implemented in other languages including Mesa, C#, Java 5.125 Silberschatz, Galvin and Gagne 2013 52

Resuming Processes within a Monitor If several processes queued on condition x, and x.signal() executed, which should be resumed? FCFS works, also can be frequently not adequate conditional-wait construct of the form x.wait(c) Where c is priority number Process with lowest number (highest priority) is scheduled next 5.126 Silberschatz, Galvin and Gagne 2013 Monitor Implementation Using Semaphores Use semaphore variables, wait and signal primitives Mutual exclusion 1. a mutex Queue and signaling 1. semaphore 2. counting x.wait() a process that invokes the operation is suspended until x.signal() x.signal() resumes one of processes (if any) that invoked x.wait() 2. counting and signal those on condition: counter next_count, and a signal semaphore next 5.127 Silberschatz, Galvin and Gagne 2013 53

Monitor Implementation Using Semaphores Variables semaphore mutex; // (initially = 1) semaphore next; // (initially = 0) int next_count = 0; Each procedure F will be replaced by wait(mutex); body of F; if (next_count > 0) signal(next) else signal(mutex); Mutual exclusion within a monitor is ensured 5.129 Silberschatz, Galvin and Gagne 2013 Monitor Implementation Condition Variables For each condition variable x, we have: semaphore x_sem; // (initially = 0) int x_count = 0; The operation x.wait can be implemented as: x_count++; if (next_count > 0) signal(next); else signal(mutex); wait(x_sem); x_count--; 5.130 Silberschatz, Galvin and Gagne 2013 54

Monitor Implementation (Cont.) The operation x.signal can be implemented as: if (x_count > 0) { next_count++; signal(x_sem); wait(next); next_count--; 5.131 Silberschatz, Galvin and Gagne 2013 Implementing Monitors using locks and condition variables http://cis-linux1.temple.edu/~giorgio/old/cis307f96/readings/pbuffer.html http://repat.de/2012/05/dining-philosophers-with-monitor-using-pthreadmutex-and-condition-variables-in-c/ 5.132 Silberschatz, Galvin and Gagne 2013 55

Synchronization Interface Examples Solaris Windows Linux Pthreads 5.136 Silberschatz, Galvin and Gagne 2013 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 Starts as a standard semaphore spin-lock If lock held, and by a thread running on another CPU, spins If lock held by non-run-state thread, block and sleep waiting for signal of lock being released Uses condition variables Uses readers-writers locks when longer sections of code need access to data Uses turnstiles to order the list of threads waiting to acquire either an adaptive mutex or reader-writer lock Turnstiles are per-lock-holding-thread, not per-object Priority-inheritance per-turnstile gives the running thread the highest of the priorities of the threads in its turnstile 5.137 Silberschatz, Galvin and Gagne 2013 56

Windows Synchronization Uses interrupt masks to protect access to global resources on uniprocessor systems Uses spinlocks on multiprocessor systems Spinlocking-thread will never be preempted Also provides dispatcher objects user-land which may act mutexes, semaphores, events, and timers Events An event acts much like a condition variable Timers notify one or more thread when time expired Dispatcher objects either signaled-state (object available) or non-signaled state (thread will block) 5.138 Silberschatz, Galvin and Gagne 2013 Linux Synchronization Linux: Prior to kernel Version 2.6, disables interrupts to implement short critical sections Version 2.6 and later, fully preemptive Linux provides: Semaphores atomic integers spinlocks reader-writer versions of both On single-cpu system, spinlocks replaced by enabling and disabling kernel preemption 5.139 Silberschatz, Galvin and Gagne 2013 57

Pthreads Synchronization Pthreads API is OS-independent It provides: mutex locks condition variable POSIX SEM extension (semaphore.h) Named semaphore By multiple unrelated processes Unnamed semaphore By threads of same process Non-portable extensions include: read-write locks spinlocks 5.140 Silberschatz, Galvin and Gagne 2013 Monitor and condition variable in pthread We can implement monitors using pthread mutex and condition variable For producer-consumer problem, need 1 pthread mutex and 2 pthread condition variables ( pthread_cond_t) 5.141 Silberschatz, Galvin and Gagne 2013 58

Check Objectives To present the concept of process synchronization. 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 examine several classical process-synchronization problems To explore several tools that are used to solve process synchronization problems Knowing how to use the tools Knowing how to implement the tools. 5.146 Silberschatz, Galvin and Gagne 2013 End of Chapter 5 Silberschatz, Galvin and Gagne 2013 59