Operating Systems
CMPSC 473
Threads
September 16, 2010 - Lecture 7
Instructor: Bhuvan Urgaonkar
•
Done
Overview of ProcessHow a process is born
related Topics
– Parent/child relationship
– fork, clone, …
• How it leads its life
– Loaded:
– Executed
Done
• 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)
today
The notion of a thread
code
data
registers
heap
stack
• 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
code
registers
data
heap
stack
URL parsing process
code
data
registers
heap
stack
Network sending process
• E.g., a Web browser
code
registers
data
heap
stack
Network reception process
code
registers
data
heap
stack
In virtual
memory
Interprets response, composes media
together and displays on browser screen
Approach #1: Writing a
multi-process Application
code
data
registers
heap
stack
URL parsing process
code
registers
data
heap
stack
Network sending process
code
registers
data
heap
stack
Network reception process
code
registers
data
heap
stack
In virtual
memory
Interprets response, composes media
together and displays on browser screen
• 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
Approach #2: Share code,
data, heap!
code
registers stack
heap
registers stack
registers stack
data
registers stack
In virtual
memory
threads
URL parsing process
Network sending process
Network reception process
Interprets response, composes media
together and displays on browser screen
• 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
(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 contains info on a single thread
(TCB)
– 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
TCBs are smaller and cheaper than PCBs
(TCB)
– 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
– 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