LINQ (Language-Integrated Query) has been around for quite a while in the world of .NET (since .NET Framework 3.5 and C# 3.0) but recently async streams (i.e. IAsyncEnumerable<T>) were added to .NET and with them came async LINQ. It allows using the richness of LINQ while reaping the benefits of async-await by asynchronously accessing databases, microservices and remote APIs.

System.Linq.Async provides the standard LINQ operators we’ve all come to expect like Where, Select, GroupBy, etc. as extensions for IAsyncEnumerable but it’s also common for developers to add their own custom ones. Doing that has some pitfalls in “old-school” (synchronous) LINQ but even more so when you throw async-await into the mix.

I’ve recently (~6 months ago) started collecting various slightly useful utility classes and extension methods related to asynchronous programming into a library: AsyncUtilities. Since there are already many useful tools in the BCL and in existing libraries out there these are quite on the fringe:

ConcurrentDictionary is a thread-safe dictionary implementation but surprisingly (at least to me) not all of its members can be safely used by multiple threads concurrently. The Thread Safety section on the ConcurrentDictionary MSDN article has this to say:

All public and protected members of ConcurrentDictionary<TKey, TValue> are thread-safe and may be used concurrently from multiple threads. However, members accessed through one of the interfaces the ConcurrentDictionary<TKey, TValue> implements, including extension methods, are not guaranteed to be thread safe and may need to be synchronized by the caller.

As some of you may know, many of the features in C# light up through “duck typing”. Duck typing is where you accept an object that behaves in a certain way (i.e. has certain methods, properties, etc.) instead of a specific type, or as is usually explained: “If it walks like a duck, and talks like a duck, it’s a duck”.

With async/await becoming more and more prevalent in modern code so has the need for async synchronization constructs. Unlike their synchronous counterparts (e.g. Monitor, Mutex, ReaderWriterLock, etc.) .NET doesn’t offer almost any built-in asynchronous synchronization constructs, but it does contain the basic building blocks to build them on your own (mainly Task, TaskCompletionSource<T> and SemaphoreSlim.WaitAsync). Stephen Toub published a series of posts (over 5 years ago) on the Parallel Framework team’s blog demonstrating that by building AsyncSemaphore, AsyncLock, AsyncReaderWriterLock and more.

However, there’s an issue with most implementations of the scoped async synchronization constructs: they usually return a task.

Since async/await was added to C# 5.0 you could await any custom awaitable type as long as it follows a specific pattern: has a GetAwaiter method that returns an awaiter that in turn has IsCompleted, OnCompleted and GetResult (more on it here). But the language is stricter when it comes to the return type of an async method. You can only return 3 types from an async method: void, Task and Task<T>.

Task is for async methods that don’t have a result (i.e. procedures) while Task<T> is for async methods that return a result (i.e. functions). That leaves async void methods which mainly exist for backwards-compatibility with event handlers (the void Button_Click(object sender, EventArgs e) kind) and should be avoided elsewhere as unhandled exceptions inside them will crash the entire process.

Those of you who are familiar with the Asynchronous Programming Model (APM) know that you need to match every BeginXXX with an EndXXX. In this post I’ll try my best to convince you that if a class implements IDisposable correctly you can forgo calling EndXXX if Dispose was already invoked. I’ve tried doing that before on Stack Overflow without much success and was faced with a lot of pushback.

TPL Dataflow is an in-process actor library on top of the Task Parallel Library enabling more robust concurrent programming. It was first introduced in the async-ctp (the preview for async/await) but was eventually released as a standalone nuget package. It abstracts away most of the hard work needed when building asynchronous and/or parallel processing code but I feel most people who might benefit from it aren’t aware of it.

I’ve been working with MongoDB for the past few years and lately the guys behind the C# driver are working on some interesting things, especially around async/await support.

This year they released a complete rewrite of the driver with an async-only API. Now since IEnumerator doesn’t support asynchronous enumeration (because MoveNext is synchronous) they used their own enumerator interface called IAsyncCursor which looks like this:

The corefxlab repository contains library suggestions for corefx which itself is a repository containing the .NET Core foundational libraries. One of the gems hidden among these libraries is ValueTask<T> that was added by Stephen Toub as part of the System.Threading.Tasks.Channels library but may be extremely useful on its own. The full implementation of ValueTask<T> can be found here, but this is an interesting subset of the API: