Synchronization 1 CSE 2431: Introduction to Operating Systems - PowerPoint Presentation

Synchronization 1 CSE 2431: Introduction to Operating Systems Instructor: Adam C. Champion, Ph.D. Reading: Chapters 6, 7 [OSC] (except Sects. 6.9, 7.4, 7.5)

Outline Critical region and mutual exclusionMutual exclusion using busy waitingSleep and WakeupSemaphoresMonitorsBarriersClassic Synchronization Problems 2

Spooling Example: No Races 3 Shared memory abc Prog.c Prog.n 4 5 6 7 F2 … … out in Process 1 Process 2 next_free = in; next_free = in int next_free ; Stores F1 into next_free ; Stores F2 into next_free ; int next_free; 1 2 4 in = next_free + 1; F1 in = next_free + 1; 3 5 6

Spooling Example: Races 4 Shared memory abc Prog.c Prog.n 4 5 6 7 … … out in Process 1 Process 2 next_free = in; next_free = in; /* value: 7 */ int next_free ; Stores F1 into next_free ; Stores F2 into next_free ; int next_free ; 1 3 2in = next_free + 1; F1in = next_free + 1; 4 5 6 F2

Critical Section (Thread/Process) N threads/processes all competing to use the same shared dataRace condition is a situation where two or more threads/processes are reading/writing same shared data; final result depends on who runs precisely whenEach thread/process has critical section: a code segment in which shared data is accessed We must ensure that when one thread/process is executing in its critical section, no other thread/ process is allowed to execute in its critical section 5

Critical Region (Critical Section) Process { while (true) { ENTER CRITICAL SECTION Access shared variables; // Critical Section; LEAVE CRITICAL SECTION Do other work } } 6

Critical Section Characteristics Mutual Exclusion: No other process must execute within its own critical section while a process is in it.Progress: If no process is waiting in its critical section and several processes are trying to get into their critical sections, then entry to the critical section cannot be postponed indefinitely.No process running outside its critical section may block other processesBounded Wait: A process requesting entry to a critical section should only have to wait for a bounded number of other processes to enter and leave the critical section.No process should have to wait forever to enter its critical section Speed and Number of CPUs: We cannot make assumptions about speeds or number of CPUs 7

Critical Regions Mutual exclusion using critical regions 8

Outline Critical region and mutual exclusionMutual exclusion using busy waitingSleep and WakeupSemaphoresMonitorsBarriersClassic Synchronization Problems 9

Synchronization With Busy Waiting Possible SolutionsDisabling InterruptsLock VariablesStrict AlternationPeterson’s solutionTSLSleep and Wakeup 10

Disabling Interrupts How does it work?Disable all interrupts just before entering a critical section and re-enable them just after leaving it. Why does it work?With interrupts disabled, no clock interrupts can occur. (The CPU is only switched from one process to another as a result of clock or other interrupts; with interrupts disabled, no switching can occur.) Problems:What if the process forgets to enable the interrupts?Multiprocessor? (disabling interrupts only affects one CPU)Only used inside OS kernels 11

Lock Variables int lock;lock=0while (lock);lock = 1; Access shared variable; // Critical Sectionlock = 0;Does the above code work? 12

Strict Alternation Thread Me; /* For two threads */{ while (true) { while (turn != my_thread_id) { }; Access shared variables; // Critical Section; turn = other_thread_id; Do other work } } Satisfies mutual exclusion but not progress. Why? Notes: While {turn != my_thread_id } {}; /* busy waiting */ A lock (variable turn) that uses busy waiting is called a spin lock 13

Using Flags int flag[2]= {false, false};Thread Me; { while (true) { flag[my_thread_id] = true; while (flag[other_thread_id]) { }; Access shared variables; // Critical Section; flag[my_thread_id] = false; Do other work } } Can block indefinitely. Why? 14

Peterson’ s Solutionint flag[2]={false, false};int turn;Thread Me; { while (true) { flag[my_thread_id] = true; turn = other_thread_id; while (flag[ other_thread_id ] && turn == other_thread_id ) { }; Access shared variables; // Critical Section; flag[ my_thread_id] = false; Do other work }} It works!!! Why? 15

Test and Set (TSL) Requires hardware supportDoes test and set atomicallychar Test_and_Set (char* target) { // All done atomically char temp = *target; *target = true; return(temp)} 16

TSL instruction 17

Other Similar Hardware Instruction Swap = TSLvoid Swap (char* x,* y);// All done atomically{ char temp = *x; *x = *y; *y = temp} 18

Outline Critical region and mutual exclusionMutual exclusion using busy waitingSleep and WakeupSemaphoresMonitorsBarriersClassic Synchronization Problems 19

Sleep and Wakeup Problem with previous solutionsBusy waitingWasting CPUPriority Inversion: High priority waits for low priority to leave critical section Low priority can never execute since high priority’s not blocked.Solution: sleep and wakeupWhen blocked, go to sleepWakeup when it’s OK to retry entering critical sectionSemaphore operation that executes sleep and wakeup 20

Types of Syncs in Linux Kernel 21 Type of Sync Scope Description Atomic operation All CPUs Atomic read-write-modify instructions to a counter Spinlock All CPUs Lock with busy waiting Semaphore All CPUsLock with blocking (wait) sleepDisabling local interruptsLocal CPUForbid interrupt handling on a single CPUDisabling global interruptsAll CPUsForbid interrupt handling on all CPUs

Review: Critical Regions What are Data RacesCritical region and mutual exclusionSynchronization using busy waitingDisabling InterruptsLock VariablesStrict AlternationPeterson’s solutionTSL 22

Sleep and Wakeup Problem with previous solutionsBusy waitingWasting CPUPriority Inversion: High-priority process/thread waits for low-priority one to leave critical section Low-priority process/thread can never execute since high-priority one is not blocked.Solution: sleep and wakeupWhen blocked, go to sleepWakeup when it is OK to retry entering the critical section 23

Producer-Consumer Problem ( Works?) 24

Outline Critical region and mutual exclusionMutual exclusion using busy waitingSleep and WakeupSemaphoresMonitorsBarriersClassic Synchronization Problems 25

Semaphores A semaphore count represents number of abstract resources. New variable having two operationsThe wait() (or down(), P()) operation acquires a resource and decrements count. The signal() (or up(), V()) operation releases a resource and increments count. Semaphore operations are indivisible ( atomic ) 26

Wait and Signal Wait(S) { // or Down(S), P(S) S->value --; if (S->value < 0) { add this process to S->list; block(); }} Signal(S) { // or Up(S), V(S) S->value ++; if (S->value <= 0) { remove a process P from S->list; wakeup (P); } } Counting semaphores: 0, …, N Binary semaphores: 0, 1 27

Counting Semaphores 28 Semaphore sem = 2 wait( sem ); display(); signal( sem ); wait( sem ); display(); signal(sem); wait(sem); display();signal(sem); P1 P2 P3 1 0 -1 0 ……

Binary Semaphores 29 Semaphore sem = 1 wait( sem ); display(); signal( sem ); wait( sem ); display(); signal(sem); P1 P2 0 -1 0 ……

Mutex: Binary Semaphore Variable with only two stateslockedunlockedMutex is used for mutual exclusionCan be implemented using TSLCan be a specialization of semaphore (simplified version of semaphore) 30

Mutex Implementation Using TSL (1) Using Test_and_Set (TSL) instruction to implementMutex_lock: Set lock =1Mutex_unlock Set lock =0 31

Mutex Implementation Using TSL (2) Implementation of mutex_lock and mutex_unlock 32

Producer-Consumer Problem Using Semaphores 33 Mutex_lock Mutex_unlock

Mutex Semaphore Implementation Using mutex_lock and mutex_unlock to implement a counter semaphorewait() (or up(), P())signal() (or down(), V()) 34

Busy Waiting Semaphore Impl. (1)class Semaphore { Mutex m; // Mutual exclusion. int count; // Resource count.public: Semaphore(int count ); void Wait(); void Signal();}; static inline Semaphore::Semaphore( int count ) { count = count; } 35

Busy Waiting Semaphore Impl. (2)voidSemaphore::Wait() { mutex_lock(m); while (count == 0) { mutex_unlock(m); yield(); mutex_lock (m); } count--; mutex_unlock (m); } 36 voidSemaphore:: Signal() { mutex_lock (m); count++; mutex_unlock(m);}

Semaphore Impl. Using Sleep and Wakeup typedef struct { int value; struct process *list;} Semaphore;Wait(Semaphore *S){ S->value:= S->value - 1; if (S->value < 0) { add this process to S->list; block(); } } 37 Signal(Semaphore *S) { S->value:= S->value + 1; if (S->value <= 0) { remove a process P from S->list; wakeup(P); }} Skipped locks here in order to provide atomicity

Tradeoffs Busy waiting (spinlock)Wastes CPU cyclesSleep and Wakeup (blocked lock)Context switch overheadHybrid competitive solutionApply spinlocks if the waiting time is shorter than the context switch timeUse sleep and wakeup if the waiting time is longer than the context switch timeWhy?What if you don’t know the waiting time? 38

Possible Deadlocks with Semaphores Example: P0 P1 share two semaphores S and Q S:=1; Q:=1; Wait(S); // S=0 ------------> Wait(Q); // Q=0 Wait(Q); // Q=-1 <--------> Wait(S); // S=-1 // P0 blocked // P1 blocked DEADLOCK Signal(S); Signal(Q); Signal(Q); Signal(S); 39

Be Careful When Using Semaphores // Violation of Mutual Exclusion Signal(mutex); mutexUnlock(); critical section criticalSection(); Wait(mutex); mutexLock(); // Deadlock Situation Wait(mutex); mutexLock (P); critical section criticalSection (); Wait(mutex); mutexLock (P); // Violation of Mutual Exclusion (omit wait(mutex)/mutexLock ()) critical section critical Section(); Signal(mutex); mutexUnlock(); // Deadlock Situation (omit signal(mutex)/mutexUnlock()) Wait(mutex); mutexLock(); critical section criticalSection(); 40

Outline Critical region and mutual exclusionMutual exclusion using busy waitingSleep and WakeupSemaphoresMonitorsBarriersClassic Synchronization Problems 41

Monitors A simpler way to synchronizeA set of programmer-defined operators monitor monitor-name { // variable declaration public entry P1(..); {... }; ...... public entry Pn (..); {...}; begin initialization code end } 42

Monitor Properties Various threads cannot access internal implementation of monitor typeEncapsulation provided by monitor type limits access to the local variables to local procedures only. Monitor construct does not allow concurrent access to all procedures defined within the monitor. Only one thread/process can be active within the monitor at a time. Synchronization is built-in. 43

Outline Critical region and mutual exclusionMutual exclusion using busy waitingSleep and WakeupSemaphoresMonitorsBarriersClassic Synchronization Problems 44

Barriers Use of a barrierProcesses approaching a barrierAll processes but one blocked at barrierLast process arrives, all are let throughProblem:Wastes CPU if workloads are unbalanced 45

Barriers 46

How to Implement a Barrier? For N processes: using messagesFor N threads: using shared variables 47

Outline Critical region and mutual exclusionMutual exclusion using busy waitingSleep and WakeupSemaphoresMonitorsBarriersClassic Synchronization Problems 48

Classic Problems Bounded buffer problemReader-writer problemDining philosophers problemSleeping barber 49

Bounded Buffer Problem (1) Producer: in an infinite loop, produces one item each iteration into the bufferConsumer: in an infinite loop, consumes one item each iteration from the bufferBuffer size: only holds at most N items 50

Bounded Buffer Problem (2) Semaphore mutex; // shared and initialized to 1Semaphore empty; // counts empty buffers, initialized to nSemaphore full; // counts full buffers, initialized to 0// Producer // Consumerrepeat repeat .... ... produce an item in nextp wait(full); .... wait(mutex); wait(empty); .... wait(mutex); remove an item from buffer to nextc .... .... add nextp to buffer signal(mutex); .... signal(empty); signal(mutex); .... signal(full); consume the item in nextc ..... ....until false; until false; 51

Readers-Writers Problem Readers: read dataWriters: write dataRule:Multiple readers can read the data simultaneouslyOnly one writer can write the data at any timeA reader and a writer cannot in critical section concurrently.Locking table: whether any two can be in the critical section simultaneously Reader Writer Reader OK No Writer No No 52

Readers-Writers Solution Does it work? Why?What if ?Any problems with this solution?Semaphore mutex, wrt; // shared and initialized to 1; int readcount; // shared and initialized to 0 // Writer // Reader wait(mutex); readcount :=readcount+1; wait( wrt ); if readcount == 1 then wait(wrt); ...... signal(mutex); writing performed .... ..... reading performed .... wait(mutex); signal(wrt); readcount:=readcount-1; if readcount == 0 then signal(wrt); signal(mutex); 53

Dining Philosophers Problem Philosophers eat/thinkEating needs 2 forksPick one fork at a time Possible deadlock?How to prevent deadlock? 54

Solution to Dining Philosophers Problem? NOT a solution to the dining philosophers problem 55

Dining Philosophers Solution (1) 56 How to implement take_forks () and put_forks () ?

Dining Philosophers Solution (2) 57

Dining Philosophers Solution (3) 58

Dining Philosophers Solution (4) 59

Dining Philosophers Solution (5) 60

The Sleeping Barber Problem N customer chairsOne barber can cut one customer’s hair at any timeIf no customer, barber sleeps 61

The Sleeping Barber Solution (1) 62

The Sleeping Barber Solution (2) 63

The Sleeping Barber Solution (3) 64

Summary (1) Critical region and mutual exclusionMutual exclusion using busy waitingDisabling InterruptsLock VariablesStrict AlternationPeterson’s solutionTSLSleep and Wakeup 65

Summary (2) Sleep and WakeupSemaphoresMonitorBarrier 66

Summary (3); Lessons Learned Synchronization is very important in OS when accessing kernel data structuresSystem performance may vary considerably, depending on the kind of sync. primitive selectedRule of thumb adopted by kernel developers: Always maximize the concurrency level in the system Concurrency level depends on two factors: Number of I/O devices that operate concurrently Number of CPUs that do productive work To maximize I/O throughput, interrupts should be disabled for short times To use CPUs efficiently, sync primitives based on spin locks should be avoided whenever possible In general, choice of sync primitives depends on what kinds of kernel control paths access the data structures 67