• January 16, 2018 | Bugs | comments | Edit
  • ConcurrentDictionary Is Not Always Thread-Safe
  • 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.

  • January 2, 2018 | Async/Await | comments | Edit
  • Duck Typing And Async/Await
  • 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”.

  • February 21, 2017 | Async/Await, Bugs, IDisposable | comments | Edit
  • The Issue With Scoped Async Synchronization Constructs
  • 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.

  • July 25, 2016 | ValueTask, Async/Await, C# 7.0, Roslyn | comments | Edit
  • Return Any (Task-Like) Type From An Async Method
  • 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.

  • June 13, 2016 | APM, IDisposable, Async/Await | comments | Edit
  • Not All Beginnings Must Have An End
  • 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.

  • May 23, 2016 | TPL Dataflow, Task Parallel Library, Async/Await | comments | Edit
  • TPL Dataflow Is The Best Library You're Not Using
  • 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.

  • December 16, 2015 | MongoDB, Async/Await, Rx, Ix, AsyncEnumerable | comments | Edit
  • Async LINQ To Objects Over MongoDB
  • 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:

  • November 30, 2015 | ValueTask, Async/Await, C# 7.0, System.Threading.Tasks.Channels, .NET Core | comments | Edit
  • On The Efficiency Of ValueTask
  • 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:

  • October 3, 2015 | Protobuf-net, Bugs | comments | Edit
  • Protobuf-net Is Broken Around DateTime
  • 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 DateTime’s original DateTimeKind.

  • July 25, 2015 | Contention, lock, Performance, System.Threading.Timer | comments | Edit
  • Surprising Contention In System.Threading.Timer
  • 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: