Is the thread created in C# user level or kernel level?

Question

Recently I was studying the operating system, and came across this question.

Is the thread created in C# user level or kernel level, like:

Thread mythread=new Thread(ThreadStart(something));

As far as I know, the process with cpu-intensive thread on kernel level could run faster than those on user level. Because the book Modern operating system says "The schedule of user-level thread will not trap into kernel,that's why they are more lightweight compared with kernl-level thread".
So I think user-level thread could not run on different cpu,which requires trapping into kernel.

And in linux,the thread created by pthread_create is kernel level. So I'm curious about the feature of .Net C#.

Answer 1

That is unix terminology, on Windows you'd say "fiber or thread". The term "green thread" is also a pretty common way to say "user thread".

It is not up to C# nor the CLR to decide this, it is the CLR host that determines this.

The host is the glue that marries the CLR to the operating system or the host process. Programs that target Silverlight, .NET Compact, .NETCore, Xbox, Windows Phone, Hololens, etc always have a custom host to adapt to the target's OS. IIS and SQL Server are common examples of unmanaged programs that have a custom host to allow managed code execution, respectively ASP.NET and CLR stored procedures. Lots of other programs allow scripting in C# with a custom host, AutoCAD is the canonical example.

So the CLR does not create a thread itself, it asks the host to do it. The ICLRTask and ICLRTaskManager interfaces get that job done. The thread pool is a host duty as well, ICorThreadpool interface.

So it is formally unknowable that you'll get a fiber or thread. Notable is that these interfaces were added at the request of the SQL Server team. They were heavily invested in fibers at the time and wanted the option to execute CLR stored procedures on a fiber. Got it all done, but at roughly the same time the multi-core revolution of the early 2000s upset that apple-cart. And they did not actually ship it. I am not aware of any host that uses fibers, albeit that you can never be sure with custom hosting being common.

So it is pretty safe to assume that you'll get a "kernel thread".

Answer 2

They are created within the context of the process. Of course there is some layers/information that has to go to the kernel, but it belongs to the process.

If this didn't happen, threads could introduce a privilege escalation which would be a huge security problem.

Answer 3

To elaborate more on Hans answer usually operating systems implement multithreading models to define the relationship between user and kernel level threads. Common ways of establishing such relationships are: many-to-one, one-to-one, many-to-many.

• Many-to-one - maps many user-level threads to a kernel thread. Used to be a thing back when multiple processing cores where not yet available.
• One-to-one - maps each user-level thread to a kernel thread. Linux and Windows operating systems implement this model.
• Many-to-Many - maps many user-level threads to many kernel threads. Before version 9 Solaris used to support this model.
• There is one last variation of many-to-many model, where user thread may still be possible to be bound to one kernel thread, this model is called two-level model.

So depending on what operating system you are and what thread API you are using there is a chance to say if a thread will be user-level or kernel, my source dates back to 2012 and things might have changed since then.

---

Bibliography

Abraham Silberschatz, Peter Baer Galvin, Greg Gagne "Operating System Concepts 9th edition" 2012 Pages 169-171

Answer 4

In C#, thread pool uses a combined approach (both user-level and kernel-level).

In a combined system, thread creation is done completely in user space, as is the bulk of the scheduling and synchronization of threads within an application. The multiple ULTs from a single application are mapped onto some (smaller or equal) number of KLTs. The programmer may adjust the number of KLTs for a particular application and processor to achieve the best overall results. In a combined approach, multiple threads within the same application can run in parallel on multiple processors, and a blocking system call need not block the entire process.

---

Bibliography

Operating Systems - Internal and Design Principles (NINTH Edition) William Stalling - Page 188