What is the difference between kernel threads and user threads?

Question

What is the difference between kernel threads and user threads? Is it that kernel thread are scheduled and executed in kernel mode? What are techniques used for creating kernel

Answer 1

Wikipedia has answers to most if not all of these questions.

http://en.wikipedia.org/wiki/Thread_(computer_science)

http://en.wikipedia.org/wiki/Thread_(computer_science)#Processes.2C_kernel_threads.2C_user_threads.2C_and_fibers

Answer 2

Essentially user threads run in the context of a user with the appropriate privilege levels e.g. user threads most certainly won't have access to kernel-level memory/data structures/routines etc. Whereas Kernel threads run in the context of the OS kernel thus giving them privileges to execute code which has access to low level kernel routines/memory/data structures.

Answer 3

What is the difference between kernel threads and user threads?

Kernel threads are privileged and can access things off-limits to user mode threads. Take a look at "Ring (Computer Security)" on Wikipedia. On Windows, user mode corresponds to Ring 3, while kernel mode corresponds to Ring 0.

What are techniques used for creating kernel threads?

This is extremely dependent upon the operating system.

now in case of user level threads Is it that this TCB is created in user's address space ?

The TCB records information about a thread that the kernel uses in running that thread, right? So if it were allocated in user space, the user mode thread could modify or corrupt it, which doesn't seem like a very good idea. So, don't you suppose it's created in kernel space?

What are these models? How are these models practically used?

Wikipedia seems really clear about that.

Answer 4

Kernel thread means a thread that the kernel is responsible for scheduling. This means, among other things, that the kernel is able to schedule each thread on different cpus/cores at the same time.

How to use them varies a lot with programming languages and threading APIs, but as a simple illustration,

void task_a();
void task_b();
int main() {
    new_thread(task_a);
    new_thread(task_b);
    // possibly do something else in the main thread
    // wait for the threads to complete their work
}

In every implementation I am familiar with, the kernel may pause them at any time. ("pre-emptive")

User threads, or "User scheduled threads", make the program itself responsible for switching between them. There are many ways of doing this and correspondingly there is a variety of names for them.

On one end you have "Green threads"; basically trying to do the same thing as kernel threads do. Thus you keep all the complications of programming with real threads.

On the opposite end, you have "Fibers", which are required to yield before any other fiber gets run. This means

• The fibers are run sequentially. There is no parallell performance gains to be had.
• The interactions between fibers is very well defined. Other code run only at the exact points you yield. Other code won't be changing variables while you're working on them.
• Most of the low-level complexities programmers struggle with in multithreading, such as cache coherency (looking at MT questions on this site, most people don't get that), are not a factor.

As the simplest example of fibers I can think of:

while(tasks_not_done) {
    do_part_of_a();
    do_part_of_b();
}

where each does some work, then returns when that part is done. Note that these are done sequentially in the same "hardware thread" meaning you do not get a performance increase from parallellism. On the other hand, interactions between them are very well defined, so you don't have race conditions. The actual working of each function can vary. They could also be "user thread objects" from some vector/array.