- Thread is a single sequence stream within a process (light weight process).
- A thread is a flow of execution through the process code, with its own program counter that keeps track of which instruction to execute next, system registers which hold its current working variables, and a stack which contains the execution history.
- Thread are executed one after another but gives the illusion as if they are executing in parallel. Each thread has different states.
- Threads are the basic unit of CPU utilization.
- Each thread belongs to exactly one process and no thread can exist outside a process.
- Each thread represents a separate flow of control.
Difference between Process and Thread
Process is heavy weight or resource intensive. While, Thread is light weight, taking lesser resources than a process.
Process switching needs interaction with
operating system. While, Thread switching does not need to interact with operating system.
In multiple processing environments, each process executes the same code but has its own memory and file resources. While, All threads can share same set
of open files, child processes.
If one process is blocked, then no other
process can execute until the first process is unblocked. While one thread is blocked and waiting, a second thread in the same task can run.
Multiple processes without using threads use more resources. While, Multiple threaded processes use fewer resources.
In multiple processes each process operates independently of the others. While, One thread can read, write or
change another thread’s data.
Types of Thread
Threads are implemented in following two ways −
User Level Threads − User managed threads.
Kernel Level Threads − Operating System managed threads acting on
kernel, an operating system core.
User Level Thread
- Within the application program
- Implemented in the user level library
- Not created using the System calls.
- Thread switching does not need to call the OS.
- Thread switching does not require Kernel mode privileges.
- User level thread can run on any operating system.
- Scheduling can be application specific in the user level thread.
- User level threads are fast to create and manage.
- No or Very less co-ordination among the threads and Kernal
- If one thread causes a page fault, the entire process blocks.
Kernel Level Thread
- Kernel knows and manages the threads.
- Instead of thread table in each process, the kernel itself has thread table (amaster one) that keeps track of all the threads in the system.
- OS kernel provides system call to create and manage threads.
- There is no thread management code in the application area.
- The Kernel performs thread creation, scheduling and management in Kernel space.
- Kernel threads are generally slower to create and manage than the user threads.
- If one thread in a process is blocked, the Kernel can schedule another
thread of the same process.
- Since kernel has full knowledge about the threads, scheduler may decide to
give more time to processes having large no. of threads.
- Kernel threads are generally slower to create and manage than the user
- Transfer of control from one thread to another within the same process requires a mode switch to the Kernel.
- Some operating system provide a combined user level thread and Kernel level thread facility.
- Solaris is a good example of this combined approach.
- In a combined system, multiple threads within the same application can run in parallel on multiple processors and a blocking system call need not block the entire process.
Multithreading models are three types:
- Many to one relationship.
- Many to many relationship.
- One to one relationship.
Many to One Model
- Many-to-one model maps many user level threads to one Kernel-level thread.
- Thread management is done in user space by the thread library (which is
- When thread makes a blocking system call, the entire process will be
blocked. Only one thread can access the Kernel at a time, so multiple
threads are unable to run in parallel on multiprocessors.
One to One Model
- Separate kernel thread to handle each user thread.
- This model overcomes the problems listed above involving blocking system calls and splitting of processes across multiple CPU.
- However the overhead of managing the one to one model is more significant, involving more overhead and slowing down the system.
Many to Many Model
- The many-to-many model multiplexes any number of user threads onto an equal or smaller number of kernel threads.
- Combines the best features of the one-to-one and many-to-one models.
- Users have no restrictions on the no. of threads created.
- Blocking kernel system calls do not block the entire process.