No, No, No - Tasks are not threads and they are not for performance!

[giscus[bot]]

No, No, No - Tasks are not threads and they are not for performance!

I often read that Task is used for multithreading in C# / .NET, but that is not the case. And it is crucial to understand why this isn't the case. We will also see which problem exactly Task is solving in the first place.

https://steven-giesel.com/blogPost/d095383f-7ea9-4419-96b8-889c6981cce0

[diptim01]

Can you talk about Multithreading like this? Also Task.WhenAll seem to improve performance but I won't say they are on a single thread

[linkdotnet]

Sure. Task.WhenAll can and most probably will increase the performance in lots of scenarios. As long as those tasks are independent of each other, you can freely pass them to Task.WhenAll. Whether or not they are scheduled on different threads doesn't really matter (the gist of that blog post).

Just imagine you have 3 API call's that you handle via Task.WhenAll. Even if you only have one thread, chances are Task.WhenAll improves your performance. The reason is that while awaiting the response of one of the calls, the thread can handle the next API request and so on. So the bottom line here is the same, utilizing all the resources as best as we can.

Does that go in the right direction of your question @diptim01 ?

[diptim01]

yes, thanks . I would like you write about multithreading as it is. Also the impact of the state machine when using async could be expensive too

[wekempf]

Modern frameworks like ASP.NET Core don't have any SynchronizationContext anymore. So whether you append ConfigureAwait(true|false) or nothing does literally make zero difference.

I see this said a lot, but I think it leads people to the wrong conclusion. Technically it's correct, ASP.NET Core doesn't have a SynchronizationContext (I wouldn't say "modern frameworks" because MAUI for instance is modern and has a SynchronizationContext) but you cannot conclude that "whether you append ConfigureAwait(true|false) or nothing does literally make zero difference". Just because the ASP.NET Core framework doesn't setup a SynchronizationContext doesn't necessarily mean your code doesn't run under one, especially if "your code" is a library. Anyone can create a SynchronizationContext and call SetSynchronizationContext to establish one. So unless your code can somehow ensure that no where in the calling stack is that done, it may well run under one even if you're using ASP.NET Core. It's dangerous to assume there is no SynchronizationContext.

[linkdotnet]

Yes and no. Even ASP.NET Core has a SynchronizationContext in particular cases (namely Blazor Server, which tries to emulate a single-threaded environment like Blazor WASM). Concluding, yes, you are right, and I will update that passage.

I also agree with you that you can't assume that there isn't a SynchronzitationContext around, but that article is meant for beginners. There are super rare cases where you roll out your own SynchronzitationContext because getting it right is not trivial. In 99% of your regular ASP.NET Core Controller there is no context around. If so, you are well past the stage of that article.

Also almost every unit testing framework has its own SynchronizationContext to be more or less complete here.

Anyway, my takeout from your input: I will be more precise. Thanks @wekempf

[GlenHandke]

This article says pretty much the exact opposite of the official documentation here:
https://learn.microsoft.com/en-us/dotnet/standard/parallel-programming/task-based-asynchronous-programming

In particular, around the 4th paragraph is this quote (emphasis mine):

For both reasons, TPL is the preferred API for writing multi-threaded, asynchronous, and parallel code in .NET.

I suggest you load the 3rd code sample in Linqpad and run it. If you add a small sleep here to simulate a non-zero amount of work being done by the task, you will see that the each task runs on a separate thread. Every. Single. Time.

Modified code:

Thread.Sleep(10); // <<-- Add this line to simulate work
CustomData data = obj as CustomData;

Output:
Task #0 created at 638120872980318797, ran on thread #27.
Task #1 created at 638120872980319065, ran on thread #26.
Task #2 created at 638120872980319069, ran on thread #9.
Task #3 created at 638120872980319071, ran on thread #28.
Task #4 created at 638120872980319073, ran on thread #24.
Task #5 created at 638120872980319075, ran on thread #10.
Task #6 created at 638120872980319078, ran on thread #11.
Task #7 created at 638120872980319080, ran on thread #22.
Task #8 created at 638120872980319082, ran on thread #21.
Task #9 created at 638120872980319085, ran on thread #20.

[wekempf]

Tasks were never "used exclusively for threading". Async I/O was always part of the design. This is precisely why TaskCompletionSource exists. Assuming a task was backed by the thread pool, or even a dedicated thread, was always wrong, regardless of the namespace or how you interpreted some portion of the documentation.

[toupswork]

I think that misconception came because the Task Parallel Library came first before using Tasks for asynchronous I/O. I remember back then. It was taught that the Task would be a thread in parallelism, and since Tasks were then used for await, the conception carried over. Also, not many C# devs know (or care to know) about low level details.

[wekempf]

No, async I/O was always part of it, and if it was taught that the task would be a thread in parallelism then it was taught wrong. It's async, not parallel, TaskCompletionSource and Synchronization context have been there since the very beginning, and there was never a guarantee of threads being used. Task.Run and the default Synchronization context use the thread pool, but that was the extent from the very beginning.

[toupswork]

I don't believe async I/O was always part of it. What I remember is them saying that Moore's law is coming to an end, CPU cores are needed to continue to improve performance, and we need to write our code to process CPU-bound work in parallel. I know the Synchronization context has always been there due to Single Threaded Apartment COM. Right, they said there was no guarantee of a thread and that it's smart enough to figure out when a new thread is warranted, and that we don't have to worry about creating threads and writing our own algorithms to determine the optimal number of threads. What I don't remember is that it came with async. I recall that we were still doing the legacy IAsyncResult.

[wekempf]

Guess my memory was faulty, as TPL came in .NET 4, while the async I/O APIs were in 4.5. Regardless, what I said still stands. TaskCompletionSource allowed for non-thread based workloads and SynchronizationContext already was in use within WinForms.