Question

Why are user level threads faster than kernel level threads?

Comments

faster in doing what?

---

faster in doing context switching

---

@ArjunSir faster interms of context switching?

Answer 1

Kernel-level threads require a context switch, which involves changing a large set of processor registers that define the current memory map and permissions. It also evicts some or all of the processor cache.

User-level threads just require a small amount of bookkeeping within one kernel thread or process.

However, the difference isn't big if your threads are predominantly doing I/O operations, as those have to go through the kernel in any case. It's most important if you're trying to implement some kind of simulation with a very large number of independant processes. In that case you need to pay careful attention to what thread synchronisation mechanisms you use, as some of them also go up to the kernel and trigger a context switch.

http://www.cs.rochester.edu/u/cli/research/switch.pdf "In general, the indirect cost of context switch ranges from several microseconds to more than one thousand microseconds for our workload."

Edit: user-level threads maintain a stack per-thread, and may or may not save the general-purpose registers depending on the architecture and the clobber rules of its calling convention. It can be as simple as dumping the registers to the stack, jumping to a new address, and popping a few registers, which may be in your cache if that thread was run recently.

Kernel-level context switches also change the memory map by writing to the TLB, and changing the security level (privilege level or "ring") of the processor. See "Performance Considerations"

Answer 2

User level threads are managed by a user level library however, they still require a kernel system call to operate. It does not mean that the kernel knows anything about thread management. Not at all, It only takes care of the execution part. The lack of cooperation between user level threads and the kernel is a known disadvantage. In this case, the kernel may not favour a process that has many threads. User level threads are typically fast. Creating threads, switching between threads and synchronizing threads only needs a procedure call. They are a good choice for non blocking tasks otherwise the entire process will block if any of the threads blocks. 

Kernel level threads are managed by the OS, therefore, thread operations (ex. Scheduling) are implemented in the kernel code. This means kernel level threads may favour thread heavy processes. Moreover, they can also utilize multiprocessor systems by splitting threads on different processors or cores. They are a good choice for processes that block frequently. If one thread blocks it does not cause the entire process to block. Kernel level threads have disadvantages as well. They are slower than user level threads due to the management overhead. Kernel level context switch involves more steps than just saving some registers. Finally, they are not portable because the implementation is operating system dependent.

S.No.	User Level Threads	Kernel Level Thread
1	User level threads are faster to create and manage.	Kernel level threads are slower to create and manage.
2	Implementation is by a thread library at the user level.	Operating system supports creation of Kernel threads.
3	User level thread is generic and can run on any operating system.	Kernel level thread is specific to the operating system.
4	Multi-threaded application cannot take advantage of multiprocessing.	Kernel routines themselves can be multithreaded.

Answer 3

Basically it depends what multi-threading model your operating system is using.

Example:

1.In case of 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.Since this kind of management wont require any system call or mode change ,no context switch, everything will be taken care by the thread libraries.Hence in this case user level threads will be faster.

Cons: 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

2. In case one to one model

There is one to one relationship of user level thread to the kernel level thread.This model provides more concurrency than the many to one model. It also another thread to run when a thread makes a blocking system call. It support multiple thread to execute in parallel on microprocessors. This is nothing but Light Weight Process.

Here i think all threads will behave the same.

3.in case of Many to Many

In this model, many user level threads multiplexes to the Kernel thread of smaller or equal numbers. The number of Kernel threads may be specific to either a particular application or a particular machine.

Providing a link for the differences.

http://www.tutorialspoint.com/operating_system/os_multi_threading.htm