Start of Lecture on January 22, 2014

Transcription

1 Start of Lecture on January 22, 2014 Chapter 3: 4: Processes Threads 1

2 Chapter 3: 4: Processes Threads 2 Reminders Likely you ve gotten some useful info for your assignment and are hopefully working on it; start early, as c can be frustrating and difficult to debug Added Lab Lectures section online Working from home FAQ Linux tutorial Introduction to Emacs I ve added references from CMPUT 201 to eclass page What are you questions and comments? Am I talking too fast? Or going too fast and you want more review?

3 Review of what we ve learned A feel for the purpose of operating systems history of their role and main services they provide, such as an interface, resource allocation, abstraction and protection System calls as interface to main services made available by OS, that processes cannot/should not be trusted to execute e.g. create process (fork), write to file (write), create shared mem (shm_open) Operating system design decisions, e.g microkernel, modules Process as entity, process states and context switching Interprocess communication: shared mem & message passing 3

4 End of Chapter 3 on Processes Any questions about processes? Or anything else? If you re too embarrassed to ask, remember that likely someone has the same question. There are no dumb questions; you are not dumb for not knowing an answer. Each question you ask makes you get more knowledgeable If you are too embarrassed, ask on the anonymous forum Chapter 3: 4: Processes Threads 4

5 CMPUT 379, Section A1, Winter 2014 January 22 and 27

6 Objectives Understand the notion of a thread : a fundamental unit of CPU utilization; the basis of multithreaded systems Understand why threads became popular and how they affected OS design Understand benefits and issues with multithreaded programming Understand how to use POSIX pthreads 6

7 Multicore (multiprocessor) versus Singlecore (single processor) In response to the need for more processing power, multiprocessor systems arose Why multiple processors rather than more powerful single processors? For example, 8 GHz instead of 4 Ghz? Heat and transmission delays (settling signals) limit the CPU speed Multi-tasking makes multiple processors useful Increase in speed from multiple processors not linear; overhead in managing multiple CPUs and multithreading 7

8 Video: Multicore vs Singlecore 8

9 Parallelism vs. Concurrency Concurrency supports more than one task by allowing multiple tasks to make progress single-processor system could have concurrency by constantly switching between processes; multi-processor system likely has concurrency! single core! T 1 T 2 T 3 T 4 T 1 T 2 T 3 T 4 T 1 time Parallelism is running more than one task simultaneously single-processor system cannot run processes in parallel core 1 T 1 T 3 T 1 T 3 T 1 core 2 T 2 T 4 T 2 T 4 T 2 time 9

10 Open problem: Scalability Analysis Performance likely scales with increasing number of cores Particularly if choose to improve precision or increase problem size since you know more computing power is available Useful to have a measure/formula of scalability Unfortunately, parallel performance is dependent on many factors, such as uni-processor power, network speed, I/O system speed, problem size, problem input and serial versus parallel instruction percentages Neither Amdahl s Law nor Gustafson s Law really tell the whole story, because its difficult to gauge how much of the problem can be parallelized 10

11 What is a thread? A thread is a basic unit of CPU utilization, with program counter, CPU register set and stack Often referred to as a light-weight process It shares code, data, system resources and other OS related information with its peer group (other threads of the same process) A thread belongs to one instantiating process, whereas a process can have many threads 11

12 Threads and Processes a thread TEXT TEXT DATA DATA STACK STACK STACK STACK a traditional process a multi-threaded process (task) 12

13 Why did multithreading arise? Separate processes can take advantage of multiprocessor systems, so its not obvious that threads are useful Considering the importance of multi-tasking (i.e. multiprogramming), particularly on interactive systems, there are already clear speed-ups from separate processes taking advantages of multiple cores So why introduce threads, and complicate things? 13

14 Benefits of threads Benefits that parallel processes and threads share: Responsiveness may allow continued execution if part of the process/ process group is blocked, especially important for user interfaces Scalability can take advantage of multiprocessor architectures Threads, however, can often be simpler and more efficient for parallelism, particularly due to: Resource sharing threads share resources of process, easier than shared memory or message passing for communication/coordination Economy cheaper than process creation, thread switching has less overhead than context switching 14

15 fork() versus pthread_create() Platform fork() pthread_create() real user sys real user sys Intel 2.6 GHz Xeon E (16 cores/node) Intel 2.8 GHz Xeon 5660 (12 cores/node) AMD 2.3 GHz Opteron (16 cores/node) AMD 2.4 GHz Opteron (8 cores/node) IBM 4.0 GHz POWER6 (8 cpus/node) IBM 1.9 GHz POWER5 p5-575 (8 cpus/node) IBM 1.5 GHz POWER4 (8 cpus/node) INTEL 2.4 GHz Xeon (2 cpus/node) INTEL 1.4 GHz Itanium2 (4 cpus/node)

16 Parallelism important, so threads important Threads arose due to importance of software speed-ups Hardware speed-ups are important, but its equally (more?) important to focus on efficiently using that hardware with clever software design Since parallelism is such a key approach for speeding up task completion, the (seemingly small) gains from threads are important 16

17 Video Break: brought to you by another fantabulous classmate 17

18 Threading examples Summing elements from 1 to N (joint task with focus on data parallelism, i.e. accessing data in parallel) Thread1: sum elements 1 to floor(n/2) Thread2: sum elements floor(n/2)+1 to N Combine (sum) results from Thread1 and Thread 2 to obtain total Compute statistics in parallel (separate tasks with focus on task parallelism, rather than accessing data in parallel) Thread1: compute mean of N elements sum arr[i] Thread2: compute 2nd moment of N elements (for Var) sum arr[i]^2 Use separately computed statistics for an end goal (e.g. profile summary) 18

19 Example: Multithreaded Server Architecture Server process runs, receiving requests and creating new threads to service those requests Since threads share much code and data with server process, there is no need to create separate processes (which require significant overhead) client (1) request server (2) create new thread to service the request thread (3) resume listening for additional client requests 19

20 And many more situations where threads make more sense than multiple processes Intensive data sharing settings: e.g. computing statistics on the same (large) dataset for machine learning large scale face recognition (finding match in large database) Situations where there are many more subtasks than available cores, since thread switches are faster than context-switches for processes threads useful for logical separation of program with multiple tabs (without need for protection between tabs), even if can t all run in parallel embarrassing" parallel tasks: easily separates into many subtasks; e.g. calculate potential energy of several thousand independent conformations of a molecule and, when done, find minimum energy conformation 20

21 Example: POSIX Pthreads Run pthreads_hello.c Run pthreads_join1.c Notice that Run pthreads_hello_arg2.c pthread_exit() called from child thread is like exit() for children in fork() pthread_join() called from parent thread is like waitpid() for forked children, except there is not the same hierarchy for threads Way that arguments are passed to threads (as pointers to variables on data segment or heap) and way threads return values to join 21