Process Synchronization: Understanding Race Conditions and Critical Regions, Slides of Operating Systems

Download Process Synchronization: Understanding Race Conditions and Critical Regions and more Slides Operating Systems in PDF only on Docsity! Lecture 11 Chapter 6: Process Synchronization (cont) Docsity.com Chapter 6: Process Synchronization • Background • The Critical-Section Problem • Peterson’s Solution • Synchronization Hardware • Semaphores • Classic Problems of Synchronization • Monitors • Synchronization Examples • Atomic Transactions Docsity.com CPU CPU  Insignificant race condition in the shopping scenario  the outcome depends on the CPU scheduling or “interleaving” of the threads (separately, each thread always does the same thing) > ./multi_shopping grabbing the salad... grabbing the milk... grabbing the apples... grabbing the butter... grabbing the cheese... > A B > ./multi_shopping grabbing the milk... grabbing the butter... grabbing the salad... grabbing the cheese... grabbing the apples... > A B Race Condition Docsity.com char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } A char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } B > ./echo Hello world! Hello world! Single-threaded echo Multithreaded echo (lucky) > ./echo Hello world! Hello world! 1 2 3 4 5 6 lucky CPU scheduling   Significant race conditions in I/O & variable sharing Race Condition Docsity.com char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } A > ./echo Hello world! Hello world! Single-threaded echo char chin, chout; void echo() { do { chin = getchar(); chout = chin; putchar(chout); } while (...); } B  Significant race conditions in I/O & variable sharing 1 5 6 2 3 4 unlucky CPU scheduling  Multithreaded echo (unlucky) > ./echo Hello world! ee.... Race Condition Docsity.com Producer / Consumer 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 } Docsity.com 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} Docsity.com  The “indivisible” execution blocks are critical regions  a critical region is a section of code that may be executed by only one process or thread at a time B A common critical region B A A’s critical region B’s critical region  although it is not necessarily the same region of memory or section of program in both processes → but physically different or not, what matters is that these regions cannot be interleaved or executed in parallel (pseudo or real) Critical Regions Docsity.com 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 Docsity.com Algorithm for Process Pi do { flag[i] = TRUE; turn = j; while (flag[j] && turn == j); critical section flag[i] = FALSE; remainder section } while (TRUE); Docsity.com Synchronization Hardware • Uniprocessors – could disable interrupts – Currently running code would execute without preemption – what guarantees that the user process is going to ever exit the critical region? – meanwhile, the CPU cannot interleave any other task • even unrelated to this race condition – Generally too inefficient on multiprocessor systems – Operating systems using this not broadly scalable Docsity.com TestAndSet Instruction • Definition: boolean TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv: } Docsity.com Solution using TestAndSet • Shared boolean variable lock., initialized to false. • Solution: do { while ( TestAndSet (&lock )) ; // do nothing // critical section lock = FALSE; Docsity.com Swap Instruction • Definition: void Swap (boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp: } Docsity.com Semaphore • Synchronization tool that does not require busy waiting – Semaphore S – integer variable • Two standard operations modify S: wait() and signal() – Less complicated • Can only be accessed via two indivisible (atomic) operations – wait (S) { while S <= 0 ; // no-op S--; } – signal (S) { S++; Docsity.com 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); Docsity.com 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 in critical section implementation • But implementation code is short • Little busy waiting if critical section rarely occupied Docsity.com Docsity.com Deadlock and Starvation • Deadlock – two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes • Let S and Q be two semaphores initialized to 1 P0 P1 wait (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 Docsity.com Classical Problems of Synchronization • Bounded-Buffer Problem • Readers and Writers Problem • Dining-Philosophers Problem Docsity.com Bounded Buffer Problem (Cont.) • The structure of the consumer process do { wait (full); wait (mutex); // remove an item from buffer to nextc signal (mutex); signal (empty); // consume the item in nextc } while (TRUE); Docsity.com 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 Docsity.com Readers-Writers Problem (Cont.) • The structure of a writer process do { wait (wrt) ; // writing is performed signal (wrt) ; } while (TRUE); Docsity.com 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 } hil (TRUE) Docsity.com Problems with Semaphores • Correct use of semaphore operations: – signal (mutex) …. wait (mutex) – wait (mutex) … wait (mutex) – Omitting of wait (mutex) or signal (mutex) (or both) Docsity.com 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 ( ….) { … } … } } Docsity.com Solution to Dining Philosophers (cont) 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 () ; } } } Docsity.com Solution to Dining Philosophers (cont) • Each philosopher I invokes the operations pickup() and putdown() in the following sequence: DiningPhilosophters.pickup (i); EAT DiningPhilosophers.putdown (i); Docsity.com 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. Docsity.com