230 likes | 337 Views
Rensselaer Polytechnic Institute CSCI-4210 – Operating Systems David Goldschmidt, Ph.D. Operating Systems {week 7 }. A need for synchronization (i). Without synchronization amongst processes (and threads), results are unpredictable. how do variables x and y become corrupted?.
E N D
Rensselaer Polytechnic Institute CSCI-4210 – Operating Systems David Goldschmidt, Ph.D. Operating Systems{week 7}
A need for synchronization (i) • Without synchronization amongst processes (and threads), results are unpredictable how dovariables x and y become corrupted?
A need for synchronization (ii) • Processes compete for resources • Once obtained, the resource isfully dedicated to a process • Often, mutual exclusion is required • No other process is allowed access to the resource • Processes cooperate with other processes • Shared resources • Specific ordering or sequencing of events all of this applies to threads, too!
Critical sections (i) • To synchronize processes(or threads), first identifythe critical sections of code • If process Pi is executing inits critical section, no other process can be executing in their critical sections • A critical section guarantees mutual exclusionto one or more resources
Critical sections (ii) • The operating system must control access to critical sections and guarantee progress: if no process isexecuting in itscritical section process selection cannot be postponed indefinitely (starvation) then and and one or more processeswish to enter theircritical sections process selection must be fair and avoid deadlock
Peterson’s solution • Peterson’s solution is a two-process solution • Processes Pj and Pk share two variables: • Variable turn indicateswhose turn it is toenter the critical section • The flag arrayspecifies if a processis ready to enter itscritical section int turn; boolean flag[2]; // Process Pj while ( true ) { flag[j] = true; // Pjready turn = k; while ( flag[k] && turn == k ) ; // busy wait // CRITICAL SECTION HERE flag[j] = false; }
Producer-Consumer Problem (i) • Model for cooperating processes: • A producer process produces information that is consumed by a consumer process • e.g. client-server, transaction processing, etc. • Implement using a shared memory segment as a shared buffer • Producer adds to the buffer • Consumer empties the buffer
Producer-Consumer Problem (ii) also known as the bounded-buffer problem
Semaphores (i) • A semaphore is a synchronization mechanism • Semaphore S is a special integer variable • OS provides two atomic operations on S: • wait(S) or P(S): • wait for a resource to become available • signal(S) or V(S): • signal that we’re done using a resource
Semaphores (ii) • The wait(S) operation decrementssemaphore S only when S is available • wait(S) { while ( S <= 0 ) { /** no-op **/ ; } S--; } this will block indefinitely in a busy wait
Semaphores (iii) • The signal(S) operation incrementssemaphore S to release a resource • signal(S) { S++; } • wait(S);// CRITICAL// SECTIONsignal(S); to protect critical section
Binary semaphores • A binary semaphore providesmutually exclusive access toa shared resource • Initialize semaphore S to 1 • Use wait(S) and signal(S) • Possible values of S are 0 and 1
Counting semaphores • A counting semaphore controls accessto a finite number of resources: • e.g. open files, network connections, shared buffers, etc. // n instances of a finite resource semaphore S = n Write pseudocode for theproducer-consumer problem usingsemaphores to synchronize accessto the shared buffer of size N
Starvation • A process faces starvation when it is forced to wait indefinitely for shared resource X as other processes use that shared resource X • Also known as indefinite blocking “starving dinosaur”
Deadlock • A system enters a deadlock state when multiple processes are unable to obtain a lock on all necessary resources • After acquiringa resource, aprocess holds thatresource indefinitely semaphore S, Q // P0 ... wait(S) wait(Q) ... signal(Q) signal(S) ... // P1 ... wait(Q) wait(S) ... signal(S) signal(Q) ... Deadlock!
Conditions for deadlock • Deadlock requires four conditions: • Mutual exclusion • Hold and wait • No preemption • Circular wait • i.e. a cycle!
Resource allocation graph • A resource allocation graph is a directed graph showing processes and resources
Rice Dining philosophers problem (i) • Five philosophers at a table • Each philosopher thinks or eats • To eat, a philosopher must pickup the closest two chopsticks • A philosopher may only pickup one chopstick at a time • Represents allocating shared resources to competing and cooperating processes
Rice Dining philosophers problem (ii) • Potential solution: • Can deadlock occur? semaphore fork[] = { 1, 1, 1, 1, 1 }; // philosopheri while ( true ) { think(); wait( fork[i] ); wait( fork[(i+1)%5] ); eat(); signal( fork[(i+1)%5] ); signal( fork[i] ); }
Handling deadlocks (i) • Allow the system to enter a deadlock state, then recover by: • Terminating one or all deadlocked processes • Rollback deadlocked processes to a safe checkpointed state • Or.... (go to the next slide)
Handling deadlocks (ii) • Guarantee that the system will neverenter a deadlocked state • Deadlock prevention ensures that at least one of the four necessary conditions is never met • Deadlock avoidance allows a system to change state by allocating resource(s) only when it is certain deadlock will not occur as a result