Structured Concurrency in C#

[giscus[bot]]

Structured Concurrency in C#

Did you ever hear about "Structured Concurrency"? If not, this article is for you. We will discover what it is, why it is useful, and what it could look like in C#.

https://steven-giesel.com/blogPost/59e57336-7c73-472f-a781-b0b79f0d47ad?utm_source=csharpdigest&utm_medium=&utm_campaign=1722

[abatishchev]

Hi, thanks for the blog post! It's interesting though process provoking.
Can be TaskScope made a struct to decrease allocations?
I'd also elide the tasks inside the lamdas, e g.

group.Run(token => Task.Delay(1000, token));

(given it would compile, and I think it would)

[linkdotnet]

Hi - thanks for the kind words!

You are right, TaskScope could indeed be a struct. It might be even better suited as we want this "short-lived" behavior.
In the average case, your TaskScope will not passed around a lot (where structs might fall short, as a copy of the TCS is created).

From a general purpose point - class is safer to use here (for that reason).

[slimshader]

I think you meant c# instead of Kotlin and this is probably better follow-up link: https://github.com/StephenCleary/StructuredConcurrency

[linkdotnet]

Thanks, I corrected the link - github.dev doesn't make much sense ;)

I really meant Kotlin, as they already have structured concurrency.

[Patrick-3000]

After reading it several times, I think I got it now: the concepts exists in Kotlin, and you implemented this concept as a PoC in C#. Like @slimshader, I also expected the code to be in Kotlin due to

How would such a Task Scope look like? Let's have a look at an example in Kotlin:

[slimshader]

Yeah, I still think "Kotlin" is wrongly used here ;) Should probably say something like "in C# mimicking Kotlin"

[linkdotnet]

You both might have convinced me. Probably will change that later ;)

[mturczyn]

Nice article, one question though: i guess eventually for each Run invocation we are doing var task = Task.Run(...) which is rather discouraged and can lead to thread pool starvation. Is it a problem here? Or maybe complete implementation accounts for that?

[linkdotnet]

You are right, Task.Run can open a cane of worms. The PoC I provided uses it anyway for a few reasons: Mainly it makes a few things easier. First: No SynchroniztationContext involved which may or may not be a good thing. Second - Direct Invocation: Without Task.Run, the action would run directly on the calling thread until the first await that actually yields (assuming there's async I/O or another asynchronous operation involved). This can lead to potential issues if, for instance, the calling context is a UI thread. This would block the UI until the first real asynchronous operation is hit. Using Task.Run ensures that the operation is offloaded from the start.

That said, you might want to differ between multiple things in the API to distinguish that and don't use Task.Run as default. Righteous so, as you might run into issues with ASP.NET Core as you starve out the Thread Pool.