To implement a threads package, there are the following two ways.
Let's describe briefly about the above two ways of implementing a thread package.
In this model of implementing the threads package completely in user space, the kernel don't know anything about them.
The advantage of implementing threads package in user space is that a user-level threads package can be implemented on an OS (Operating System) that doesn't support threads.
All of these implementations have the same general structure as illustrated in the figure given below.
In this method of implementing the threads package entirely in the kernel, no any run-time system is need in each as illustrated in the figure given below.
In this, there is no any thread table in each process. But to keep track of all the threads in the system, the kernel has the thread table.
Whenever a thread wants to create a new thread or destroy an existing thread, then it makes a kernel call, which does the creation or destruction just by updating the kernel thread table.
The thread table of the kernel holds each registers, state, and some other useful information of the thread.
Here the information is the same as with the user-level threads.
This information is a subset of the information that traditional kernels maintains about each of their single-threaded processes, that is, the process state.
In addition to these, to keep track of processes, the kernel also maintains the traditional process table.
Now, let's discuss briefly about another two method given here.
In this method, each kernel-level thread has some set of user-level threads that take turns using it.
The goal of this scheduler activation work are to mimic the functionality of kernel threads, but with better performance and greater flexibility generally associated with threads packages implemented in user space.