What's C# threading type?

Question

Between three types of threading (kernel-level, user-level and hybrid), which type does C# (or more generally .NET) use?

Answer 1

Kernal Thread (1 : 1)

The term "kernel threads" can be used to refer to actual threads that run entirely in kernel space or it can refer to user-space threads scheduled by the kernel. The term "kernel-supported" threads means the latter, threads that run in user-space but are facilitated by the kernel, which usually means the kernel schedules them.

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.

User Level Thread (N : 1)

"User-level threads" usually means threads visible to user space. That is, what you create when you call your threading standard's "create thread" function. Generally, the term "user-level thread" is used to mean a thread created by the application code regardless of how it's implemented by the system. It may be a pure user-space thread with little to no kernel support or it may be a thread scheduled by the kernel.

Hybrid Threading (M : N) [WikiPedia]

M:N maps some M number of application threads onto some N number of kernel entities, or "virtual processors." This is a compromise between kernel-level ("1:1") and user-level ("N:1") threading. In general, "M:N" threading systems are more complex to implement than either kernel or user threads, because changes to both kernel and user-space code are required. In the M:N implementation, the threading library is responsible for scheduling user threads on the available schedulable entities; this makes context switching of threads very fast, as it avoids system calls.

.Net thread are user-level thread that uses the Win32 API and wraps it up as a nice Framework!

---

More details can be found :

• Thread (computing)
• Kernel threads vs. Kernel-supported threads vs. User-level threads
• user thread and kernel thread
• Is Thread a Kernel Object ?

Answer 2

It's not up to the C# itself, but rather the runtime - CLR.

.Net can be considered to support two modes:

• User-land only scheduling (or Windows UMS). In this mode one user land thread can can perform a context switch into another user mode thread without actually changing the kernel thread. This mode adds a lot of coding overhead, but saves precious 10-20 microseconds in a kernel level context switch.
• Hybrid model (most popular by far). In this model managed code requires access to the kernel, such as reading a file. Through a set of API the code execution travels from user-land .NET calls, into the Windows API, into the kernel, driver, HAL layer and physical drive. And back through the call stack fetching the data. If a context switch is initiated by the thread scheduler, then user thread and kernel thread are changed.

Direct kernel mode threading is not allowed, because managed code does not have privileges to run in the kernel mode. It can only call Windows API, which in turn switch into the kernel mode.

---

If you use a Thread, Task, ThreadPool - CLR uses hybrid model. A hybrid model is used because CLR creates managed object to represent that classes. Any managed code runs in the user-land. However, every thread that is not created as a fibber (see below), be it in a thread pool or not, has got underlying kernel data structures. Kernel data structures are used to hold the thread's kernel state - kernel thread id, create and exit times, process id, start thread address, security access token, dozen of timers, CPU register, kernel stack etc. All these need to be updated during a context switch, but we just take the hit of roughly 10-20 * 10^-6 sec it takes.

If you use a managed wrapper around Ums set of C++ calls (like CreateUmsThreadContext, UmsThreadYield and many others) - CLR attempts to use UMS mode. But this is only specific to the few threads you specifically and manually manipulate. Your application will still use the hybrid model, just a few manually picked threads (fibbers) will be manually yielded between each other in user mode. But even in this mode, at some point OS task scheduler will initiate a kernel thread switch, so you are not stuck executing UMS scheduled threads for ever.

For completeness,

• Kernel-mode scheduling is a very low level mechanism that is accessible from the kernel only. What it means is that you can only use it, if you develop OS internals or some sort of a driver. Such scheduling is difficult to use, any mistake and the whole OS is frozen/stuck/crashed/BSODed or transits to any other unpredictable state. Kernel level threading requires enormous development and testing effort. For example, Windows task scheduler or memory management service use kernel mode scheduling. Can you imaging how much time it took to write these components so that they are stable in a highly multithreaded environment?