Threads
Motivation
- Processes are expensive
Processes creation is use fork() model which causes a lot of duplicate memory space and process context
- Context switch
Requires saving and restoring of process information
- Communication between process:
Independent -> No easy way to pass info
Independent -> No easy way to pass info
IPC -> OS involvement
- Thread was invented to overcome the problems with process model
- Threads is use to do multitasking within a process: Waiting for IO, loading the graphics (can do together at the same time)
Basic Idea
- Traditional process has one thread
The program does one instruction each time
Hardware can execute more through instruction level parallelism
- Add more threads: Multiple parts of the program can be executed at the same time conceptually (Program is faster)
Process and threads
A single process have multiple threads (Multithreaded process)
Between threads
Shared:
- Text segment (code)
- Heap
- Data
- PID
- Context
Not shared:
- GPR
- Special register
- Stack (We do not want the parameters to be overwritten by different threads)
Unique info between each threads:
- thread id
- register
- Stack
<Insert slide 10/11>
When we are switching the thread, we are just manipulating the pointers.
We are not saving the context like in a process context switch
Benefits:
- Enconomy
- Enconomy
Less resources
- Resource sharing
Additional communcation (Could be problem)
- Responsiveness
Can let other components do something else
- Scalability
You can use one core. Multi core will not be useful in threads
Problems:
- Synch around shared memory is much worse
- Synch around shared memory is much worse
All memory except stack is shared (Race condition)
- System call concurrency
Parallel system call is possible
- Process behavior;
fork() duplicates process, what about threads
If a single thread does exit(), what about others?
If a single thread calls exec(), what about other threads
which thead receives a signal sent to process?
Threads Models
Kernel vs User Thread
User thread
- Thread is implemented as user lib
- A runtime system handles thread related operation
- Kernel not aware of threads in process
<Insert slide 16>
OS sees it as one thread
Pros
- Any OS
- thread operations are just libcalls
- More configurable and flexible
Cons:
- Limited to one core (OS does not know about different threads) (No scheduler)
- Limited to one core (OS does not know about different threads) (No scheduler)
- One thread using IO operation will block the entire process ( Threads is useless)
Kernel thread
- Thread is implemented in OS
- Thread operation is handled as syscalls
- Thread operation is handled as syscalls
- Thread level scheduling is possible:
Thread schedules thread not processes
- Kernel often use threads for its own execution
<Insert slide 18>
Pros:
- kernal schedule on thread levels
- kernal schedule on thread levels
More than one thread in same pricess can run sim on multiple cpu
One trhead can be block while another thread of same process is running
Cons:
- Thread op are now syscalls
- Thread op are now syscalls
Slower and more resources
- Less flexible
Expensive and overkill
Hybrid model
- OS schedule on kernel threads
- Use thread can bind to kernel thread
Threads on modern processor
- Threads started as software mechanism
(User space lib -> OS aware mech)
- There are hardware support on modern processors
(SMT) -> Simultaneous multi threading aka hyperthreading
Thread in UNIX
POSIX thread
pthread
- can be implemented as user (Linux)/kernal thread