Operating Systems CMPSC 473

1. Operating SystemsCMPSC 473 Threads September 16, 2010 - Lecture 7 Instructor: Bhuvan Urgaonkar

2. Overview of Process-related Topics Done • How a process is born • Parent/child relationship • fork, clone, … • How it leads its life • Loaded: • Executed • CPU scheduling • Context switching • Where a process “lives”: Address space • OS maintains some info. for each process: PCB • Process = Address Space + PCB • How processes request services from the OS • System calls • How processes communicate • Some variants of processes: threads • How processes die Done Done Done (project 1) today

3. The notion of a thread code • Roughly, a flow of execution that is a basic unit of CPU utilization • E.g., a process, a KCP data heap registers stack thread A single-threaded process

4. Multi-process Applications • Many applications need to do multiple activities simultaneously • E.g., Web browser • Parse requested URL and find IP address from DNS server • Use system calls to send request to some Web server • Receive response • Assemble response and display it • Can you give another example? • Solution #1: Write multi-process application as follows: • forks off multiple processes, each responsible for a certain “flow of execution” • Programmer’s choice/decision • Employ IPC mechanisms for these processes to communicate (coming up soon) • We already know about signals, how many have used pipes? Shared memory? • Employ synchronization (ccoming up in a few lectures)

5. Multi-process Applications • Many applications need to do multiple activities simultaneously • E.g., Web browser • Parse requested URL and find IP address from DNS server • Use system calls to send request to some Web server • Receive response • Assemble response and display it • Can you give another example? • Approach #1: Write multi-process application as follows: • forks off multiple processes, each responsible for a certain “flow of execution” • Programmer’s choice/decision • Employ IPC mechanisms for these processes to communicate (coming up soon) • We already know about signals, how many have used pipes? Other kinds of shared memory? • Employ synchronization (coming up in a few lectures)

6. Approach #1: Writing a multi-process Application In virtual memory code data code data code data code data • E.g., a Web browser heap heap heap heap registers stack registers stack registers stack registers stack URL parsing process Network sending process Network reception process Interprets response, composes media together and displays on browser screen

7. Approach #1: Writing a multi-process Application In virtual memory code data code data code data code data • E.g., a Web browser • Potentially, lot of redundancy in code, data, and heap segments! • Virtual memory wastage => More contention for precious RAM => More waiting for slow swap device => Reduction in computer’s throughput • Also, TLB and cache contention between processes part of the same application heap heap heap heap registers stack registers stack registers stack registers stack URL parsing process Network sending process Network reception process Interprets response, composes media together and displays on browser screen

8. Approach #2: Share code, data, heap! In virtual memory code • E.g., a Web browser • Share code, data, heap via shared memory mechanisms (coming up) • Make them part of the same address space • Or let kernel or a user-library handle sharing of these parts of the address spaces and let the programmer deal only with synchronization issues • Kernel vs. User threads heap data registers stack registers stack registers stack registers stack threads URL parsing process Network sending process Network reception process Interprets response, composes media together and displays on browser screen

9. (Old) Process Address Space

10. (New) Address Space with Threads • All threads in a process share the same address space

11. Implementing Threads • Given what we know about processes, implementing threads is “easy” • Idea: Break the PCB into two pieces: • Thread-specific stuff: Processor state • Process-specific state: Address space and OS resources (e.g., open files)

12. Thread Control Block (TCB) • TCB contains info on a single thread • Just processor state and pointer to corresponding PCB • PCB contains info on the containing process • Address space and OS resources, but NO processor state!

13. Thread Control Block (TCB) • TCBs are smaller and cheaper than PCBs • Linux TCB (thread_struct) has 24 fields • Linux PCB (task_struct) has 106 fields

14. Context Switching • TCB is now the unit of a context switch • Ready queue, wait queues, etc. now contain pointers to TCBs • Context switch causes CPU state to be copied to/from the TCB • Context switch between two threads of the same process • No need to change address space • No TLB flush • Context switch between two threads of different processes • Must change address space, sometimes invalidating cache • This will become relevant when we talk about virtual memory

15. Prep. for Project 2 • Learn pthreads calls • Multi-threaded server and clients • https://computing.llnl.gov/tutorials/pthreads/#PthreadsAPI • Use Solaris or Linux • Thread management • pthread_create, pthread_exit • Threads synchronization • Choose one of the following • pthread_join, pthread_detach • pthread_mutex_init, pthread_mutex_lock, pthread_mutex_unlock, pthread_mutex_destroy • We will study the “mutex” problem closely starting next week