Threads

A thread is the smallest unit of programmed instructions that can be managed independently and processing that can be performed by an operating system. A thread is also called a lightweight process. Multiple threads can be existing within the same process that shares common resources such as memory. If a process has multiple threads of control, it can perform more than one task at a time. Threads within a process share the same virtual memory space but each has a separate stack, and possibly "thread-local storage" if implemented. They are lightweight because a context switch is simply a case of switching the stack pointer and program counter and restoring other registers, whereas a process context switch involves switching the MMU context as well.

                                                             

 Fig: Threads[/caption]

For example a web browser can have a thread to display images or text while another thread retrieves data from the network.
Also in a word processor, a background thread may check spelling and grammar while a foreground thread processes user input (keystrokes), while yet a third thread loads images from the hard drive, and a fourth does periodic automatic backups of the file being edited.

Advantages of using Threads

• They is easy and inexpensive to create. It is 10 times as faster to create than process
  (studies done by Mach developers)
• It takes less time to terminate the thread than the process.
• The use of thread provides concurrency within the process.
• Thread minimizes context switching time (i.e. switching between two threads within the same
  process is faster)
• It enhances efficiency in communication between different executing programs. (Threads
  within the same process share data and code memory which allows them to communicate
  without involving the kernel)
• Utilization of multiprocessor architectures to a greater scale and efficiency

Types/ model of Threads

1. User Level Threads

•  Thread management is done in the userspace of main memory by a user-level thread library.
•  The user-level or programmer takes the information from the thread library which contains the code about the creation, destroy, schedule, execution, and restoring of threads.
•  Kernel doesn't know about these threads
•  User Level Threads are faster to create and manage

Advantages:

1.  The most obvious advantage of this technique is that a user-level threads package can be implemented on an Operating System that does not support threads.
2.  User-level threads do not require modification to operating systems.
3. Simple Representation: Each thread is represented simply by a PC, registers, stack, and a small control block, all stored in the user process address space.
4. Simple Management: This simply means that creating a thread, switching between threads, and synchronization between threads can all be done without the intervention of the kernel.
5.  Fast and Efficient: Thread switching is not much more expensive than a procedure call.

Disadvantages:

1. User-Level threads are not a perfect solution as with everything else, they are a trade-off. Since User-Level threads are invisible to the OS they are not well integrated with the OS. As a result, Os can make poor decisions like scheduling a process with idle threads, blocking a process whose thread initiated an I/O even though the process has other threads that can run, and unscheduling a process with a thread holding a lock. Solving this requires communication between kernel and user-level thread manager.
2. There is a lack of coordination between threads and the operating system kernel. Therefore, process as a whole gets one-time slice irrespective of whether the process has one thread or 1000 threads within. It is up to each thread to relinquish control to other threads.
3.  User-level threads require non-blocking systems call i.e., a multi-threaded kernel. Otherwise, the entire process will block in the kernel, even if there are runnable threads left in the processes.
   For example, if one thread causes a page fault, the process blocks.

2. Kernel Level Threads

• The thread that is defined and managed by direct kernel of Operating system is kernel-level threads
• Kernel performs thread creation, scheduling, and management
• Kernel threads are used in the internal working of the operating system
•  Kernel threads are slower to create and manage

Advantages:

1. Because kernel has full knowledge of all threads, Scheduler may decide to give more time to a process having a large number of threads than a process having a small number of threads.
2.  Kernel-level threads are especially good for applications that frequently block.

Disadvantages:

1.  The kernel-level threads are slow and inefficient. For instance, threads operations are hundreds of times slower than that of user-level threads.
2.  Since kernel must manage and schedule threads as well as processes. It requires a full thread control block (TCB) for each thread to maintain information about threads. As a result, there is significant overhead and increase in kernel complexity.

User implementation of threads

Implement the entire threads package in userspace without the kernel knowing about them. When one thread gets blocked by a system call, all user-level threads get blocked. As far as the kernel is concerned, it is managing ordinary, single-threaded processes. A user-level threads package can be implemented on an operating system that does not support threads.
The threads run on top of a run-time system, which is a collection of procedures that manage threads. When threads are managed in user space, each process needs its own private thread table to keep track of the threads in that process. This table is analogous to the kernel’s process table, except that it keeps tracks only of the per-thread properties, such as each thread’s program counter, stack pointer, registers, state, and so forth. The thread table is managed by the run-time system. When a thread is moved to ready state or blocked state, the information needed to restart it is stored in the thread table, exactly the same way as the kernel stores information about processes in the
process table.

 

Kernel implementation of threads

The kernel’s thread table holds each thread registration, state, and other information. The information is the same as with the user-level threads, but now kept in the kernel instead of the user space (inside the run-time system). This information is the subset of information that
traditional kernels maintain about their single-threaded process, that is, the process state. In addition, the kernel also maintains the traditional process table to keep track of processes.

 

Multi-threading Models

Some operating systems 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. Multi-threading models are three types

• Many too many relationships.
• Many to one relationship.
• One to one relationship.

Many to Many Model

The many-to-many model multiplexes any number of user threads onto an equal or smaller number of kernel threads.
The following diagram shows the many-to-many threading model where 6 user-level threads are multiplexing with 6 kernel-level threads. In this model, developers can create as many user threads as necessary and the corresponding Kernel threads can run in parallel on a multiprocessor machine. This model provides the best accuracy on concurrency and when a thread performs a blocking system call, the kernel can schedule another thread for execution.

                                       

Many to One Model

The many-to-one model maps many user-level threads to one Kernel-level thread. Thread management is done in userspace by the thread library. When the 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.

If the user-level thread libraries are implemented in the operating system in such a way that the system does not support them, then the Kernel threads use the many-to-one relationship modes.

                                              

One to One Model

There is the one-to-one relationship of the user-level thread to the kernel-level thread. This model provides more concurrency than the many-to-one model. It also allows another thread to run when a thread makes a blocking system call. It supports multiple threads to execute in parallel on
microprocessors.
The disadvantage of this model is that creating a user thread requires the corresponding Kernel thread. OS/2, Windows NT and windows 2000 use one to one relationship model.