CODEWITHSUNDEEP
c#multithreading
ProofTheEngi
ProofTheEngi

Reputation: 87

Is one C# thread one CPU thread?

I am wondering if one C# thread uses up one CPU thread as example:

If you have a CPU with eight threads, for example: 4790k and you start two new C# threads, do you lose two threads? Like 8 - 2 = 6?

Upvotes: 5

Views: 4564

Answers (4)

A. Porteghali
A. Porteghali

Reputation: 11

Just want to share an experience as an enthusiastic programmer. I hope it may help someone. I was developing a code, defining a certain amount of tasks which were planned to start in a fraction of a second interval. however, I noticed that all tasks were run in a group of 8! I was wondering whether the number of CPU thread imposed a limitation here? Actually, I expected all tasks, say 40, should've started exactly in a queue, one by one, according to time interval I set in the code. My old laptop had a CPU corei5, with 4 cores and 8 threats. the same number of 8 made me so confused so that I wanted to hit my head on a wall :)

Task<object>[] tasks = new Task<object>[maxLoop];
        String[] timeStamps = new String[maxLoop];
        
        for (int i = 0; i < maxLoop; i++)
        {
            tasks[i] = SubmitRequest();
            timeStamps[i] = DateTime.Now.TimeOfDay.ToString();
            await Task.Delay(timeInterval);
        }
        await Task.WhenAll(tasks);

After reading the Microsoft documents, I reached to this page:ThreadPool.SetMinThreads(Int32, Int32) Method

According to the page, "By default, the minimum number of threads is set to the number of processors on a system. You can use the SetMinThreads method to increase the minimum number of threads." then I added this to the code:

ThreadPool.SetMinThreads(maxLoop, maxLoop);

and the problem was resolved. Just notice unnecessarily increasing the minimum threads may decrease performance. If too many tasks start at the same time, it may impact the overall speed of the task. So normally, it was advised to leave it to the thread pool to decide with its own algorithm for allocating threads.

Upvotes: 0

Niels Filter
Niels Filter

Reputation: 4528

As JRLambert already touched on, you can have many threads running on the same core.

When you spawn new threads in your .NET application, you are not actually multi-"tasking" at all. What's happening is time-slicing. Your CPU will constantly switch between the different threads letting them seem like they're working in parallel. However, a core can only work on a single thread at any given time.

When implementing the Task Parallel Library (TPL) for instance, and your machine has multiple cores, you'll see that the cores get more equally distributed work loads, than when simply spawning new threads. Microsoft really did some fantastic work with TPL to simplify a multi-thread asynchronous environment without having to do heavy work with the Thread Pool and Synchronization primitives as we may have had to in the past.

Have a look at this YouTube video. He describes time-slicing vs. multi-tasking quite well.

If you're not familiar with TPL yet, Sacha Barber has a fantastic series on Code Project.

Upvotes: 0

v.oddou
v.oddou

Reputation: 6775

The virtual machine (CLR) is free to do whatever it wants if I recall correctly. There are implementations called green threads for example, that don't necessarily map managed threads to native threads. However, of course, in .NET on a desktop x86, the implementation we know try hard to really map to system threads.

Now this is one layer, but it still says nothing about the CPU. The OS scheduler will let a hardware thread (virtualized because of hyper threading) execute a native thread when it decides it's OK.

There is such a thing known as overcommit which speaks of when too many native threads wants to run (are present in the OS's scheduler ready queue), but the CPU have only that many threads to use, so some remains waiting, until their weight which is an internal measure of the OS scheduler decides that it's their turn.

You can check this document for more information: CFS Scheduler

Then as for the CLR, maybe this question: How does a managed thread work and exist on a native platform?

Indeed in the discussion the useful MSDN page Managed and unmanaged threading in Windows explains that:

An operating-system ThreadId has no fixed relationship to a managed thread, because an unmanaged host can control the relationship between managed and unmanaged threads. Specifically, a sophisticated host can use the Fiber API to schedule many managed threads against the same operating system thread, or to move a managed thread among different operating system threads.

For very interesting reasons. One of course is the freedom of virtual machine implementation. But another one is the freedom of passing between the native/managed barrier with lots of flexibility as explained on this page. Notably the fact that native threads can enter to managed application domains backwards, and see the virtual machine allocating a managed thread object automatically. This management is maintained using thread id hashes. Crazy stuff :)

Actually, we can see on page CLR Inside Out that the CLR has configurable thread API mapping. So quite flexible, and that proves indeed that you cannot say for sure that one C# thread == one native thread.

Upvotes: 3

Jacob Lambert
Jacob Lambert

Reputation: 7679

Threads are not cores. In the case you gave, your computer has 8 cores (4 physical and 4 logical) that can handle threads.

Computers handle hundreds of threads at once and switch in-between them extremely fast. If you create a Thread class in your C# application, it will create a new thread that will execute on any of the cores on your CPU. The more cores that you have, the faster your computer runs because it can handle more threads at once (there are other factors at play in the speed of the computer than just how many cores you have).

Upvotes: 4

Related Questions