CS 153 Design of Operating Systems Spring 18

Transcription

1 CS 153 Design of Operating Systems Spring 18 Lectre 9: Synchronization (1) Instrctor: Chengy Song Slide contribtions from Nael Ab-Ghazaleh, Harsha Madhyvasta and Zhiyn Qian

2 Cooperation between Threads What is the prpose of threads? Threads cooperate in mltithreaded programs Why? To share resorces, access shared data strctres» Threads accessing a memory cache in a Web server To coordinate their exection» One thread exectes relative to another CS 153 Lectre 9 Synchronization 2

3 Threads: Sharing Data int nm_connections = 0; web_server() { while (1) { int sock = accept(); thread_fork(handle_reqest, sock); handle_reqest(int sock) { ++nm_connections; Process reqest close(sock); CS 153 Lectre 9 Synchronization 3

4 Threads: Cooperation Threads volntarily give p the CPU with thread_yield Ping Thread while (1) { printf( ping\n ); thread_yield(); Pong Thread while (1) { printf( pong\n ); thread_yield(); CS 153 Lectre 9 Synchronization 4

5 Synchronization For correctness, we need to control this cooperation Threads interleave exections arbitrarily and at different rates Schedling is not nder program control We control cooperation sing synchronization Synchronization enables s to restrict the possible interleavings of thread exections CS 153 Lectre 9 Synchronization 5

6 What abot processes? Does this apply to processes too? Yes! Processes are a little easier becase they don t share by defalt Bt share the OS strctres and machine resorces so we need to synchronize them too Basically, the OS is a mlti-threaded program CS 153 Lectre 9 Synchronization 6

7 Shared Resorces We initially focs on coordinating access to shared resorces Basic problem If two concrrent threads are accessing a shared variable, and that variable is read/modified/written by those threads, then access to the variable mst be controlled to avoid erroneos behavior Over the next cople of lectres, we will look at Exactly what problems occr How to bild mechanisms to control access to shared resorces» Locks, mtexes, semaphores, monitors, condition variables, etc. Patterns for coordinating accesses to shared resorces» Bonded bffer, prodcer-consmer, etc. CS 153 Lectre 9 Synchronization 7

8 A First Example Sppose we have to implement a fnction to handle withdrawals from a bank accont: withdraw (accont, amont) { balance = get_balance(accont); balance = balance amont; pt_balance(accont, balance); retrn balance; Now sppose that yo and yor father share a bank accont with a balance of $1000 Then yo each go to separate ATM machines and simltaneosly withdraw $100 from the accont CS 153 Lectre 9 Synchronization 8

9 Example Contined We ll represent the sitation by creating a separate thread for each person to do the withdrawals These threads rn on the same bank machine: withdraw (accont, amont) { balance = get_balance(accont); balance = balance amont; pt_balance(accont, balance); retrn balance; withdraw (accont, amont) { balance = get_balance(accont); balance = balance amont; pt_balance(accont, balance); retrn balance; What s the problem with this implementation? Think abot potential schedles of these two threads CS 153 Lectre 9 Synchronization 9

10 Interleaved Schedles The problem is that the exection of the two threads can be interleaved: Exection seqence seen by CPU balance = get_balance(accont); balance = balance amont; balance = get_balance(accont); balance = balance amont; pt_balance(accont, balance); pt_balance(accont, balance); Context switch What is the balance of the accont now? CS 153 Lectre 9 Synchronization 10

11 Shared Resorces Problem: two threads accessed a shared resorce Known as a race condition (remember this bzzword!) Need mechanisms to control this access So we can reason abot how the program will operate Or example was pdating a shared bank accont Also necessary for synchronizing access to any shared data strctre Bffers, qees, lists, hash tables, etc. CS 153 Lectre 9 Synchronization 11

12 When Are Resorces Stack (T1) Thread 1 Shared? Thread 2 Stack (T2) Stack (T3) Thread 3 Local variables? Not shared: refer to data on the stack Each thread has its own stack PC (T2) Never pass/share/store a pointer to a local variable on the stack for thread T1 to another thread T2 Heap Static Data Code PC (T3) PC (T1) Global variables and static objects? Shared: in static data segment, accessible by all threads Dynamic objects and other heap objects? Shared: Allocated from heap with malloc/free or new/delete CS 153 Lectre 9 Synchronization 12

13 How Interleaved Can It Get? How contorted can the interleavings be? We'll assme that the only atomic operations are reads and writes of individal memory locations Some architectres don't even give yo that! We'll assme that a context switch can occr at any time We'll assme that yo can delay a thread as long as yo like as long as it's not delayed forever... get_balance(accont); balance = get_balance(accont); balance =... balance = balance amont; balance = balance amont; pt_balance(accont, balance); pt_balance(accont, balance); CS 153 Lectre 9 Synchronization 13

14 What do we do abot it? Does this problem matter in practice? Are there other concrrency problems? And, if so, how do we solve it? Really difficlt becase behavior can be different every time How do we handle concrrency in real life? CS 153 Lectre 9 Synchronization 14

15 Mtal Exclsion Mtal exclsion to synchronize access to shared resorces This allows s to have larger atomic blocks What does atomic mean? Code that ses mtal called a Only one thread at a time can execte in the All other threads are forced to wait on entry When a thread leaves a, another can enter Example: sharing an ATM with others What reqirements wold yo place on a critical section? CS 153 Lectre 9 Synchronization 15

16 Critical Section Reqirements Critical sections have the following reqirements: 1) Mtal exclsion (mtex) 2) Progress If one thread is in the, then no other is A thread in the will eventally leave the critical section If some thread T is not in the, then T cannot prevent some other thread S from entering the 3) Bonded waiting (no starvation) If some thread T is waiting on the, then T will eventally enter the 4) Performance The overhead of entering and exiting the is small with respect to the work being done within it CS 153 Lectre 9 Synchronization 16

17 Abot Reqirements There are three kinds of reqirements that we'll se Safety property: nothing bad happens Mtex Liveness property: something good happens Progress, Bonded Waiting Performance reqirement Performance Properties hold for each rn, while performance depends on all the rns Rle of thmb: When designing a concrrent algorithm, worry abot safety first (bt don't forget liveness!). CS 153 Lectre 9 Synchronization 17

18 Mechanisms For Bilding Critical Sections Locks Primitive, minimal semantics, sed to bild others Semaphores Basic, easy to get the hang of, bt hard to program with Monitors High-level, reqires langage spport, operations implicit Architectre help Atomic read/write» Can it be done? CS 153 Lectre 9 Synchronization 18

19 How do we implement a lock? First try pthread_trylock(mtex) { if (mtex==0) { mtex= 1; retrn 1; else retrn 0; Thread 0, 1, //time to access critical region while(!pthread_trylock(mtex); // wait <critical region> pthread_nlock(mtex) Does this work? Assme reads/writes are atomic The lock itself is a critical region! Chicken and egg Compter scientist strggled with how to create software locks CS 153 Lectre 9 Synchronization 19

20 Second try int trn = 1; while (tre) { while (trn!= 1) ; trn = 2; otside of while (tre) { while (trn!= 2) ; trn = 1; otside of This is called alternation It satisfies mtex: If ble is in the, then trn == 1 and if yellow is in the then trn == 2 (trn == 1) (trn!= 2) Is there anything wrong with this soltion? CS 153 Lectre 9 Synchronization 20

21 Third try two variables Bool flag[2] while (flag[1]!= 0); flag[0] = 1; flag[0]=0; otside of while (flag[0]!= 0); flag[1] = 1; flag[1]=0; otside of We added two variables to try to break the race for the same variable Is there anything wrong with this soltion? CS 153 Lectre 9 Synchronization 21

22 Forth try set before yo check Bool flag[2] flag[0] = 1; while (flag[1]!= 0); flag[0]=0; otside of flag[1] = 1; while (flag[0]!= 0); flag[1]=0; otside of Is there anything wrong with this soltion? CS 153 Lectre 9 Synchronization 22

23 Fifth try doble check and back off Bool flag[2] flag[0] = 1; while (flag[1]!= 0) { flag[0]=0; flag[0] = 0; wait a short time; flag[0] = 1; otside of flag[1] = 1; while (flag[0]!= 0) { flag[1]=0; flag[1] = 0; wait a short time; flag[1] = 1; otside of CS 153 Lectre 9 Synchronization 23

24 Six try Dekker s Algorithm Bool flag[2]l Int trn = 1; flag[0] = 1; while (flag[1]!= 0) { //while if(trn == 2) { flag[0] = 0; while (trn == 2); flag[0] = 1; //if flag[0]=0; trn=2; otside of flag[1] = 1; while (flag[0]!= 0) { //while if(trn == 1) { flag[1] = 0; while (trn == 1); flag[1] = 1; //if flag[1]=0; trn=1; otside of CS 153 Lectre 9 Synchronization 24

25 Peterson's Algorithm int trn = 1; bool try1 = false, try2 = false; while (tre) { try1 = tre; trn = 2; while (try2 && trn!= 1) ; try1 = false; otside of while (tre) { try2 = tre; trn = 1; while (try1 && trn!= 2) ; try2 = false; otside of This satisfies all the reqirements Here's why... CS 153 Lectre 9 Synchronization 26

26 Peterson's Algorithm: analysis int trn = 1; bool try1 = false, try2 = false; while (tre) { { try1 (trn == 1 trn == 2) 1 try1 = tre; { try1 (trn == 1 trn == 2) 2 trn = 2; { try1 (trn == 1 trn == 2) 3 while (try2 && trn!= 1) ; { try1 (trn == 1 try2 (try2 (yellow at 6 or at 7)) 4 try1 = false; { try1 (trn == 1 trn == 2) otside of while (tre) { { try2 (trn == 1 trn == 2) 5 try2 = tre; { try2 (trn == 1 trn == 2) 6 trn = 1; { try2 (trn == 1 trn == 2) 7 while (try1 && trn!= 2) ; { try2 (trn == 2 try1 (try1 (ble at 2 or at 3)) 8 try2 = false; { try2 (trn == 1 trn == 2) otside of (ble at 4) try1 (trn == 1 try2 (try2 (yellow at 6 or at 7)) (yellow at 8) try2 (trn == 2 try1 (try1 (ble at 2 or at 3))... (trn == 1 trn == 2) CS 153 Lectre 9 Synchronization 27

27 Some observations This stff (software locks) is hard Hard to get right Hard to prove right It also is inefficient A spin lock waiting by checking the condition repeatedly Even better, software locks don t really work Compiler and hardware reorder memory references from different threads Something called memory consistency model Well beyond the scope of this class J So, we need to find a different way Hardware help; more in a second CS 153 Lectre 9 Synchronization 28