Thanks for the writeup, very good (and quite important!) collection indeed. :-) Thanks for the SemaphorSlim hint (and the update comment on the danger of being locked on abortion).
Maybe worth mentioning, that it can get dangerous if one does not specify the factory method return type to be of Func but Action in the Lazy example. If so, one ends up getting an async void without even noticing it. Also one has to think really good if a Task.Run is truly needed? A dev should ask own self: "What is the true benefit of going to another thread (pool allocated) function if on await it'll wait anyway?" Of course, one should not confuse and match words block and wait. Blocking means a thread is idling and can not be reused elsewhere, while wait means the thread was released and some other thread is doing the other work. I guess that by mixing the semantics of these words is somehow the root of all problems with async / await. So one should also then ask own self: "Why not rather make it sync all the way if its only CPU bound action/operation?"
Luckily (or perhaps not for all, depends how you take it, i.e. what your code does) dotnet core now does not use a sync context as the old one (ASP.NET speaking, the UI frameworks still do as it does make more sense) did, so the new thread is reused back, and no context switching occurs, saving some resource, but opens the pit of "implicit parallelism" as S. Cleary states well in his article.
A wonderful collection on this topic if you are interested is provided by D. Fowler of course:
This repository has examples of broken patterns in ASP.NET Core applications
ASP.NET Core Diagnostic Scenarios
The goal of this repository is to show problematic application patterns for ASP.NET Core applications and a walk through on how to solve those issues.
It shall serve as a collection of knowledge from real life application issues our customers have encountered.
Common Pitfalls writing scalable services in ASP.NET Core
Next you can find some guides for writing scalable services in ASP.NET Core. Some of the guidance is general purpose but will be explained through the lens of writing web services.
You are absolutely right, I posted this because I felt the main topics have been discussed elsewhere and this was some bits and bobs I had that wasn't written anywhere.
The AspNetCoreDiagnosticScenarios repo you link to I happen to be (a minor) contributor to, and I have a full-length talk on being responsible with async (i/o bound vs thread bound) and about the consequences with being irresponsible with it: Async in C# - The Good, the Bad and the Ugly
by chance, I happen to cover all your points in that talk! Like I say "Luckily (or perhaps not for all, depends how you take it, i.e. what your code does)" almost word-for-word 😄
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the writeup, very good (and quite important!) collection indeed. :-) Thanks for the
SemaphorSlimhint (and the update comment on the danger of being locked on abortion).Maybe worth mentioning, that it can get dangerous if one does not specify the factory method return type to be of Func but Action in the Lazy example. If so, one ends up getting an async void without even noticing it. Also one has to think really good if a Task.Run is truly needed? A dev should ask own self: "What is the true benefit of going to another thread (pool allocated) function if on await it'll wait anyway?" Of course, one should not confuse and match words block and wait. Blocking means a thread is idling and can not be reused elsewhere, while wait means the thread was released and some other thread is doing the other work. I guess that by mixing the semantics of these words is somehow the root of all problems with async / await. So one should also then ask own self: "Why not rather make it sync all the way if its only CPU bound action/operation?"
Luckily (or perhaps not for all, depends how you take it, i.e. what your code does) dotnet core now does not use a sync context as the old one (ASP.NET speaking, the UI frameworks still do as it does make more sense) did, so the new thread is reused back, and no context switching occurs, saving some resource, but opens the pit of "implicit parallelism" as S. Cleary states well in his article.
A wonderful collection on this topic if you are interested is provided by D. Fowler of course:
This repository has examples of broken patterns in ASP.NET Core applications
ASP.NET Core Diagnostic Scenarios
The goal of this repository is to show problematic application patterns for ASP.NET Core applications and a walk through on how to solve those issues. It shall serve as a collection of knowledge from real life application issues our customers have encountered.
Common Pitfalls writing scalable services in ASP.NET Core
Next you can find some guides for writing scalable services in ASP.NET Core. Some of the guidance is general purpose but will be explained through the lens of writing web services.
NOTE: The examples shown here are based on experiences with customer applications and issues found on Github and Stack Overflow.
P.S. sorry for the 101 async / await pep talk, but sometimes I feel (morally obliged) this has to be posted somewhere on the internet
You are absolutely right, I posted this because I felt the main topics have been discussed elsewhere and this was some bits and bobs I had that wasn't written anywhere.
The AspNetCoreDiagnosticScenarios repo you link to I happen to be (a minor) contributor to, and I have a full-length talk on being responsible with async (i/o bound vs thread bound) and about the consequences with being irresponsible with it: Async in C# - The Good, the Bad and the Ugly
by chance, I happen to cover all your points in that talk! Like I say "Luckily (or perhaps not for all, depends how you take it, i.e. what your code does)" almost word-for-word 😄