Difference Between Kernel, Kernel-Thread and User-Thread

Difference between kernel threads and user threads in a multi core cpu?

I am intimately familiar with neither Python nor Node.js, but I can help you out with the rest.

In my estimation, the easiest way to understand user threads is to understand how the kernel manages (kernel) threads in a single-core system. In such a system, there is only one hardware thread, i.e. only one thread can physically be in execution on the CPU at any given time. Clearly, then, in order to run multiple threads simultaneously, the kernel needs to multiplex between the threads. This is called time sharing: the kernel juggles between threads, running each for just a bit (usually in the order of, say, 10 ms) before changing to another thread. The time quantum given to each process is short enough so that it appears that the threads are being run in parallel, while in reality they are being run sequentially. This kind of apparent parallelism is called concurrency; true parallelism requires hardware support.

User threads are just the same kind of multiplexing taken one step further.

Every process initially starts with only one kernel thread, and it will not get more unless it explicitly asks the kernel. Therefore, in such a single-threaded process, all code is executed on the same kernel thread. This includes the user-space threading library responsible for creating and managing the user threads, as well as the user threads themselves. Creating user threads doesn't result to kernel threads being created - that is exactly the point of user-space threads. The library manages the user threads created by itself in much the same way that the kernel manages kernel threads; they both perform thread scheduling, which means that user-threads, too, are run in turns for a short time, one at a time.

You'll notice that this is highly analogous to the kernel thread scheduling described above: in this analogy, the single kernel thread the process is running on is the single core of the CPU, user threads are kernel threads and the user-space threading library is the kernel.

The situation remains largely the same if the process is running on multiple kernel threads (i.e. it has requested more threads from the kernel via a system call). User threads are just data structures local to the kernel thread they are run on, and the code executed on each user thread is simply code executed on the CPU in the context of the kernel thread; when a user thread is switched to another, the kernel thread essentially performs a jump and starts executing code in another location (indicated by the user thread's instruction pointer). Therefore, it is entirely possible to create multiple user threads from multiple kernel threads, although this would pretty much defeat the purpose of using user threads in the first place.

Here is an article about multithreading (concurrency) and multiprocessing (parallelism) in Python you might find interesting.

Finally, a word of warning: there is a lot of misinformation and confusion regarding kernel threads floating around. A kernel thread is not a thread that only executes kernel code (and threads executing kernel code aren't necessarily kernel threads, depending on how you look at it).

I hope this clears it up for you - if not, please ask for clarification and I'll try my best to provide it.

Difference between user-level and kernel-supported threads?

Edit: The question was a little confusing, so I'm answering it two different ways.

OS-level threads vs Green Threads

For clarity, I usually say "OS-level threads" or "native threads" instead of "Kernel-level threads" (which I confused with "kernel threads" in my original answer below.) OS-level threads are created and managed by the OS. Most languages have support for them. (C, recent Java, etc) They are extremely hard to use because you are 100% responsible for preventing problems. In some languages, even the native data structures (such as Hashes or Dictionaries) will break without extra locking code.

The opposite of an OS-thread is a green thread that is managed by your language. These threads are given various names depending on the language (coroutines in C, goroutines in Go, fibers in Ruby, etc). These threads only exist inside your language and not in your OS. Because the language chooses context switches (i.e. at the end of a statement), it prevents TONS of subtle race conditions (such as seeing a partially-copied structure, or needing to lock most data structures). The programmer sees "blocking" calls (i.e. data = file.read() ), but the language translates it into async calls to the OS. The language then allows other green threads to run while waiting for the result.

Green threads are much simpler for the programmer, but their performance varies: If you have a LOT of threads, green threads can be better for both CPU and RAM. On the other hand, most green thread languages can't take advantage of multiple cores. (You can't even buy a single-core computer or phone anymore!). And a bad library can halt the entire language by doing a blocking OS call.

The best of both worlds is to have one OS thread per CPU, and many green threads that are magically moved around onto OS threads. Languages like Go and Erlang can do this.

system calls and other uses not available to user-level threads

This is only half true. Yes, you can easily cause problems if you call the OS yourself (i.e. do something that's blocking.) But the language usually has replacements, so you don't even notice. These replacements do call the kernel, just slightly differently than you think.

---

Kernel threads vs User Threads

Edit: This is my original answer, but it is about User space threads vs Kernel-only threads, which (in hindsight) probably wasn't the question.

User threads and Kernel threads are exactly the same. (You can see by looking in /proc/ and see that the kernel threads are there too.)

A User thread is one that executes user-space code. But it can call into kernel space at any time. It's still considered a "User" thread, even though it's executing kernel code at elevated security levels.

A Kernel thread is one that only runs kernel code and isn't associated with a user-space process. These are like "UNIX daemons", except they are kernel-only daemons. So you could say that the kernel is a multi-threaded program. For example, there is a kernel thread for swap. This forces all swap issues to get "serialized" into a single stream.

If a user thread needs something, it will call into the kernel, which marks that thread as sleeping. Later, the swap thread finds the data, so it marks the user thread as runnable. Later still, the "user thread" returns from the kernel back to userland as if nothing happened.

In fact, all threads start off in kernel space, because the clone() operation happens in kernel space. (And there's lots of kernel accounting to do before you can 'return' to a new process in user space.)

What is the difference between kernel threads and user threads?

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.

user threads v.s. kernel threads

I heard that, on Linux/Unix, kernel threads(such as those of system calls) get executed faster than user threads.

This is a largely inaccurate statement.

• Kernel threads are used for "background" tasks internal to the kernel, such as handling interrupts and flushing data to disk. The bulk of system calls are processed by the kernel within the context of the process that called them.

• Kernel threads are scheduled more or less the same way as user processes. Some kernel threads have higher than default priority (up to realtime priority in some cases), but saying that they are "executed faster" is misleading.

Is it true that on a single processor box, when user thread is running, kernel will be suspended?

Of course. Only one process can be running at a time on a single CPU core.

That being said, there are a number of situations where the kernel can interrupt a running task and switch to another one (which may be a kernel thread):

• When the timer interrupt fires. By default, this occurs 100 times every second.
• When the task makes a blocking system call (such as select() or read()).
• When a CPU exception occurs in the task (e.g, a memory access fault).

User thread, Kernel thread, software thread and hardware thread

"Hardware thread" is a bad name. It was chosen as a term of art by CPU designers, without much regard for what software developers think "thread" means.

When an operating system interrupts a running thread so that some other thread may be allowed to use the CPU, it must save enough of the state of the CPU so that the thread can be resumed again later on. Mostly that saved state consists of the program counter, the stack pointer, and other CPU registers that are part of the programmer's model of the CPU.

A so-called "hyperthreaded CPU" has two or more complete sets of those registers. That allows it to execute instructions on behalf of two or more program threads without any need for the operating system to intervene.

Experts in the field like nice, short names for things. Instead of talking about "complete sets of context registers," they just call them "hardware threads."

---

Related Topics