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.
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
SemaphoreSlim.WaitAsync). Stephen Toub published a series of posts (over 5 years ago) on the Parallel Framework team’s blog demonstrating that by building
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
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:
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
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:
Protocol Buffers by Google are a great mechanism for serializing (and deserializing) structured data in a very fast and efficient way. Protobuf-net is Marc Gravell’s port of Protocol Buffers for the .NET ecosystem.
While being very efficient, protobuf-net has a big issue when deserializing .NET’s
DateTimes. Behind the scenes
DateTimes are converted into Unix-Time which is a count (of ticks in this case) starting from the Unix Epoch (1970/01/01 UTC). When deserializing back to .NET protobuf-net adds that count to a
DateTime representing the Epoch-Time resulting in the correct
DateTime value. The issue with this process is that it loses the
While profiling our application’s performance we stumbled upon a surprising contention point inside
System.Threading.Timer (I say surprising as
System.Threading.Timer is the more appropriate timer for multi-threaded environments out of the available timers)
This can be demonstrated by executing the following piece of code: