The transition to asynchronous code changes a lot of the basics we're used to. There's usually much more concurrency in these systems and that becomes more challenging to diagnose when things go wrong. #dotnet#aspnetcore
The threads are usually switching between lots of concurrent operations as various IO operations complete. Here's an example of visualizing lots of concurrent operations happening in the parallel tasks window. The right is parallel stacks. Async stacks vs OS thread stacks.
Essentially the async logical stacks are linked lists of objects stored on the heap. There may not be any code executing if a request is waiting on IO for example.
A big problem with diagnostics in this area is that it isn't explicitly modeled in the runtime and that means the tools need to reverse engineer the original intent. This means heuristics are used everywhere to detect common usage patterns
Visual Studio does a stellar job with this. Here's an example of 2 parallel operations fired from a task and being waited on asynchronously
• • •
Missing some Tweet in this thread? You can try to
force a refresh
4 months I got to spend time with friends and family. We went on cruises, and had lots of beach days. The kids learned how to swim at the beach. They got to live with grandparents for 3 of those 4 months. Got to spend my birthday here for the first time in over 10 years.
Got to experience what it would be like to work remotely from Barbados. Started a relationship between Microsoft and the UWI (University of the West Indies). Joined a WhatsApp group of coders of Barbados and am doing what I can to make them love .NET 🤣.
.NET APIs you didn't know existed. StringBuilder.GetChunks docs.microsoft.com/en-us/dotnet/a…. You can use this API to get access to the internal buffer of the StringBuilder instead of turning it into a String. #dotnet
StringSplitOptions.TrimEntries docs.microsoft.com/en-us/dotnet/a…. Ever split a string and didn't want to trim each entry? Me too, now you can use this enum to do it!
There are some common issues I see when people use ConcurrentDictionary:
- Dealing with the fact that GetOrAdd executes the creation callback more than once. This means if you create something expensive, it'll happen more than once. (this is documented) #dotnet
- If you create a disposable object in your factory and it gets called multiple times, the created objects will never be disposed.
- Making sure asynchronous factories and are called once. (making all callers wait on the same value).
Here's a contrived example of the resource leak. The code runs a couple of concurrent operations and uses GetOrAdd to cache a FileStream. This will call File.OpenRead potentially multiple times which will result in opening a handle to the resource and not disposing it.
Week 2 of analyzing how goroutines pause and resume and how the networking stack and other subsystems interact with the primitives exposed by the runtime.
One of the things I appreciate about C# is how many low level features are directly exposed to users. #golang#dotnet
In golang, it's not possible for you to implement pausing and resuming of goroutines other than by using the primitives go offers, channels, network IO, timers (sleep). This is fine for most applications but comes with additional overhead.
I also learned that go's GC doesn't move pointers and therefore there's no way to pin memory when working with C interop. There's no equivalent to passing around a GCHandle in go, just don't pass things with managed pointers to C.
Tonight, we'll discuss some of the little known low level optimizations made to async/await in .NET Core 3.x! By now, most of you know what asynchronous programming is, if not look at docs.microsoft.com/en-us/dotnet/c…#dotnet
As a primer, remember I can write asynchronous logic in a sequential manner. The keywords async/await originated in C# 5.0 8 years ago, though there were inspirations in other languages that lead to this final syntax. I get sad when people think javascript invented async/await ;)
To see what the compiler generates, we decompile the async state machine back into C# to compare sharplab.io/#v2:D4AQTAjAsA…. The state machine keeps track of local state and all of the required context to pause and resume at each await point.
Somethings that we tried to change when building ASP.NET Core:
- Removing all first chance exceptions (where possible).
- Remove scanning all assemblies on Startup to find things (controllers/hubs/plugins/etc). We try to do a bulk of the work during build...
So that startup time isn't impacted by the scan and load all types in all assemblies.
- Code over configuration. Configuration is read and configured by imperative code.
- DI everywhere, anywhere we call your code, you can inject dependencies
- No static APIs, the entire framework is testable and uses constructor injection. Places that use the service locator pattern only do so because they themselves are factories. The root of the universe is the is DI container.