A thread is a process code execution flow, with its own programme counter keeping track of which instruction to execute next, system registers holding its current working variables, and a stack containing the history of execution.
A thread shares few details with its peer threads such as code segment, data segment, and open files. If one thread changes a memory segment of code item, all other threads can see that.
Often a lightweight process is called a thread. Threads offer a means to improve parallel application performance. Threads reflect a software approach to improving performance of operating system by which the overhead thread is equivalent to a classical operation.
Each thread belongs to exactly one process and no thread can exist outside a process. - thread represents a separate flow of control. Threads were used in efficient implementation of network servers and web servers. They also provide an effective basis for parallel running of multiprocessor applications on shared memory.
|1.||Method is heavy weight, or intensive resource.||Thread is light weight and takes less resources than a process.|
|2.||The switching process requires interaction with the operating system.||The switching of threads should not interfere with the operating system.|
|3.||Each method executes the same code in multiple processing environments but possesses its own memory and file resources.||All threads will share same collection of open files, child processes.|
|4.||If one process is blocked, then no other process can be performed before unblocking of the first process.||A second thread will run in the same task while one thread is blocked and awaited.|
|5.||Multiple processes are using more resources without using the threads.||Multiple processes with threads are using less resources.|
|6.||Each method operates in several processes independently of the others.||One thread can read, write or change another thread's data.|
Threads are applied in two ways −
In this case, the thread control kernel is unaware of thread existence. The thread library contains code to create and break threads, to transfer messages and data between threads, to schedule execution of threads and to save and restore thread contexts. The application commences with a single thread.
Thread management in this case is performed by the Kernel. The application area is not protected by thread management code. The operating system supports Kernel Threads directly. Any application is programmable for multithreaded. Within a single process all threads within an application are supported.
The Kernel preserves context information inside the process for the process as a whole and threads for individuals. Thread-based scheduling is performed by the Kernel. The Kernel creates, manages and handles threads in Kernel space. Generally, kernel threads are slower to produce and maintain than user threads.
Some operating system have a combined thread for the user level and a thread facility for the kernel level. Solaris is a strong case in point for this combined approach. In a combined system , multiple threads will run parallel on multiple processors within the same programme, and the entire process need not be interrupted by a blocking system call. Multithreaded models consist of three types-
The many-to-many model multiplexes any number of user threads on to a number of kernel threads equal to or smaller.
The diagram below shows the many-to-many threading model where 6 user-level threads multiplex with 6 kernel-level threads. Developers can build as many user threads as possible in this model and on a multiprocessor system the corresponding kernel threads can run in parallel. This model offers the best competition efficiency and the kernel will schedule another thread for execution when a thread performs a blocking system call.
Many-to-one model maps many threads at the user level to one thread at the Kernel level. Thread management is done by thread library in user space. As thread triggers a blocking system call, blocking the entire process. Only one thread can access the Kernel at a time, so that multiple threads on multiprocessors can not run in parallel.
If the user-level thread libraries are implemented in the operating system in such a way that they are not supported by the system, then many-to-one relationship modes are used by the Kernel threads.
The User-level thread relationship to the kernel-level thread is one-to-one. This model gives more flexibility than the many-to-one model. It also allows another thread to run while a thread is making a call to the blocking method. It allows parallel execution on microprocessors with multiple threads.
Disadvantage of this model is that it includes the corresponding Kernel thread to create user threads. OS/2, windows NT, and windows 2000 use one-to-one model of relationship.
|Sr No||User-Level Threads||Kernel-Level Thread|
|1.||User-level threads are faster to create and manage.||Threads at the kernel level are slower to build and manage.|
|2.||Implementation is via user-level thread library.||Operating system supports Kernel thread creation.|
|3.||User-level thread is generic and can execute on any operating system.||Kernel-level thread is specific to the operating system.|
|4.||Multi-threaded applications cannot take advantage of multiprocessing.||Kernel routines themselves can be multithreaded.|