Operating Systems CMPSC 473 Threads September 16, Lecture 7 Instructor: Bhuvan Urgaonkar

Overview of Process- related Topics 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 (project 1) Done today

codedata registersstack heap The notion of a thread Roughly, a flow of execution that is a basic unit of CPU utilization –E.g., a process, a KCP thread A single-threaded process

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)

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)

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

Approach #1: Writing a multi-process Application 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 codedata registersstack heap URL parsing process codedata registersstack heap codedata registersstack heap codedata registersstack heap Network sending process Network reception process Interprets response, composes media together and displays on browser screen In virtual memory

Approach #2: Share code, data, heap! 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 URL parsing processNetwork sending process Network reception process Interprets response, composes media together and displays on browser screen In virtual memory code data registersstack heap registersstackregistersstackregistersstack threads

(Old) Process Address Space

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

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)

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!

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

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

Prep. for Project 2 Learn pthreads calls –Multi-threaded server and clients – –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