COMP 3430 Robert Guderian

Transcription

1 Operating Systems COMP 3430 Robert Guderian file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 1/58 1

2 Threads Last week: Processes This week: Lesser processes! file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 2/58 2

3 Relevant chapters Chapter 26 file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 3/58 3

4 Why threads Wrangling processes is complicated (sooooooooon) Can we do more than 1 task at a time with minimal overhead? file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 4/58 4

5 Caveat The two (or more) tasks should be highly related! They should be components of solving the same problem. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 5/58 5

6 Threads "Lightweight processes" Processes can have 1 or more thread. Linux, by default, has 1 thread. We can multi-thread a process - parallelism! file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 6/58 6

7 Threads vs Processes Processes: 1 PCB, image each Threads: Share PCB, image, memory file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 7/58 7

8 What it looks like in memory Each thread recieves its own stack Stack <-> state! Really, they'd all need their own stack... one return shouldn't return all the things file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 8/58 8

9 What it looks like, visually file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 9/58 9

10 Inexpesive to make Threads are incredibly cheap to make no new PCB needed no new memory needs to be allocated The OS sees these as on big process file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 10/58 10

11 But... Nothing is free: Sharing memory Threads share the heap + text, but not kindly We need to manage shared resources between threads file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 11/58 11

12 Thread dangers OS Manages isolation But, only isolation between processes Threads are not safe from each other file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 12/58 12

13 Thread dangers Threads can smash the stack of another thread, change that thread's data. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 13/58 13

14 But wait, there's more Scheduling (handwave): threads get a slice process's time in the CPU The process runs its threads during its time slice Switching between threads is cheap, switching between processes is expensive Don't need to load a process/load memory (threads share memory) file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 14/58 14

15 Great, why use processes? Threads are part of processes, therefore they execute on the same CPU Hyperthreading lets >1 execute at once... maybe. Multiple cores can execute multiple threads, depending on CPU archetecture. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 15/58 15

16 Why? Processes need to do many things Think about something that requires input from a user Users are PAINFULLY SLOW compared to a CPU 60 WPM \(\rightarrow\) 1hz. 1hz < hz file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 16/58 16

17 So 1 thread waiting for a human 1 thread waiting for disk or network I/O 1 thread updating something on the screen (progress bar) file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 17/58 17

18 I'm sold How! file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 18/58 18

19 Posix threads or, pthreads pthread_create - create a thread pthread_exit - kill a thread pthread_join - wait for threads to join file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 19/58 19

20 pthreads and compiling Compiling any code with pthreads requires we pass an link in a library: gcc lpthread Adding this to a makefile helps us not have to remember... file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 20/58 20

21 Simple threading The threads get work, never have to report back to the main process. Print to the screen Send data to the network Sadly, uncommon... See simple_thread.c file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 21/58 21

22 Thread pools Thread pools are a common programming pattern. Consider: program that fetches files from hard drive/network for consumption Any queryable service file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 22/58 22

23 Thread example Webservers Webservers are good examples of multithreaded software 1 thread waiting for requests Issues that request to a thread to fulfill. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 23/58 23

24 How would we do it? Conceptually main () { while (1) { req = getrequest() Thread t = new Thread() t.reply(req) } } file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 24/58 24

25 Webserver, reality Creating and destroying (or abandoning) threads is wasteful Concept: Create all the threads when we create the process. Reuse them to solve incoming work file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 25/58 25

26 Prerequisites for pooling This only works if: All the incoming work is similar We have a long-lived thread that issues requests This thread often listens for input file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 26/58 26

27 Issuing tasks How can we issue tasks to workers? Use shared memory? Threads share memory, so that's free! The workers poll for work This is a concurrency problem - solve this to get into pooling file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 27/58 27

28 Concurrency problems Operations aren't atomic They don't happen at once Two workers WILL fetch the same work. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 28/58 28

29 Concurrency, intro Problems: Two (or more) threads are attempting to access/change the same data They can't both change the data They shouldn't look at stale data file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 29/58 29

30 Critical section, intro If we are looking at data that can change, we need to lock it "I have the conch, I will speak" ONE thread is allowed to inspect/change a variable at a time file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 30/58 30

31 Mutual exclusion Me OR you are looking at this... not both xor! (x or y) and not (x and y) file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 31/58 31

32 Mutex What could possibly go wrong? Check out this code Is there anything else we can do to help? volatile? Reload from memory on each use file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 32/58 32

33 The tools Posix gives us these tools to work with: pthread_mutex_t - mutex variable pthread_mutex_lock - stop, wait for exclusive access pthread_mutex_unlock - free the lock when done pthread_mutex_trylock - non-blocking test of the lock file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 33/58 33

34 thread_clobber2.c Added a simple lock in this code Notice anything different? Much much much slower! Not really running in parallel, is it... file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 34/58 34

35 thread_clobber3.c Locking aggressively is a BAD idea. Blocks the other thread from doing any work. Called "starvation" - we starve the other thread from the resources it requires to run. Cleaned up how to parallelize this in this code file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 35/58 35

36 clobbering, conclusion It's easy to be naive with locking/threads Consider your problem Think about it as a parallel problem Can we lock less? Do we need to lock? file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 36/58 36

37 pthread_exit and pthread_join Threads are void* return type. Abstract! Can return anything This has to be allocated somewhere, though... Don't return a stack pointer! file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 37/58 37

38 Returning and catching Simply using return won't work... pthread_exit(valueptr) can return a value back to the caller pthread_join(mythread, valueptr) can catch that pointer, we can use it. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 38/58 38

39 Thread pools Many programs are queryable services 1 thread listens for incoming requests n threads process the request, return result to requester - called workers We need to issue tasks to the workers file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 39/58 39

40 Thread pool? Deadpool Wait, Thread pool (c) Marvel file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 40/58 40

41 Thread pools - tasks How do we issue tasks to workers? Threads make sharing memory simple Have a staging area for data that we are passing to workers Listener stores data in well-known shared location Worker copies data from shared buffer, does task file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 41/58 41

42 Issuing work What do we do when we get new work Need one (of many) threads to do the work Just one thread, not all of them Just one, you say... do we have tools for this? file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 42/58 42

43 Issuing work Of course! Mutex! Need a mutex to protect reading and writing the data being passed How do we intelligently check for new work file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 43/58 43

44 Why check? We can signal the threads that there is new work that needs to be consumed. Posix gives us condition variables. Condition variables block a thread until it is signaled that it can continue. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 44/58 44

45 Condition varibles Worker threads run a near-infinite loop - while (!done). Check for more work: pthread_mutex_lock( &workdatalock ); pthread_cond_wait( &workready, &workdatalock ); workready - condition variable workdatalock - mutex to lock the critical variables pthread_cond_wait unlocks the mutex, returns when the condition variable is signaled file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 45/58 45

46 pthread_cond_wait Great tool: Stop this thread, free lock, wait (blocked state). Returns when work appears, AND we have the lock. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 46/58 46

47 Query thread The query thread has to signal when new work has appeared. // wait for more work, put it in shared buffer // get the lock pthread_mutex_lock( &workdatalock ); databuffer = somedata; // signal that data is available pthread_cond_signal(&workready); pthread_mutex_unlock( &workdatalock ); file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 47/58 47

48 Explained: pthread_cond_signal wakes a thread, which will get the lock when we unlock workdatalock. (We don't need workdatalock... but...) file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 48/58 48

49 file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 49/58 49

50 In case you haven't watched The Holy Grail... It's not that easy. Does pthread_cond_signal wake just one thread? Of course not We need more condition variables to handle this problem... file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 50/58 50

51 pthread_cond_signal pattern pthread_mutex_lock( &workdatalock ); while (!workavailable) pthread_cond_wait( &workready, &workdatalock ); workavailable must be protected by lock. Many threads will wake, only one will see workavailable as true. The worker MUST COPY the data from the shared buffer, set workavailable to false. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 51/58 51

52 pthread_cond_signal pattern The query thread: Must wait for work to be consumed Oh look, another condition variable Workers signal query thread once work has been consumed (copied) file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 52/58 52

53 Example Waking threads to do something thread_signal.c thread_signal2.c file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 53/58 53

54 Are workers available? A few ways to know this: Query thread waits on workavailable == true until it is cleared Data is consumed This doesn't imply a thread is ready for a signal Have a counting variable - how many availble threads there are. Don't call pthread_cond_signal if no one is listening. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 54/58 54

55 Functions: pthread_cond_t - variable type for condition variables pthread_cond_init(&threadready, NULL); - init the conditions, optional attributes pthread_cond_wait(&threadready, &lock); - free the lock, wait on condition pthread_cond_signal&threadready); - Signal the waiting thread(s) pthread_cond_broadcast(&threadready); - Signal ALL waiting threads (good for cleanup) file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 55/58 55

56 Thread Pools, conclusion 1 Locks and conditions control the workflow of the workers We must wrangle the workers, signals must go both ways. file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 56/58 56

57 Thread Pools, conclusion 2 Can make thread pools more generic Pass function pointers, arguments to workers Run generic tasks! file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 57/58 57

58 References Good example Threads visualized Condition wait In-class code examples file:///users/robg/dropbox/teaching/ /slides/04_threads/index.html?print-pdf#/ 58/58 58