• July 25, 2016 | ValueTask, async-await, 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, IDispable, 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, 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 repo 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:

  • July 2, 2015 | Task.Run, async-await, TaskCreationOptions, | comments | Edit
  • LongRunning Is Useless For Task.Run With async-await
  • Back in the olden days of .NET 4.0 we didn’t have Task.Run. All we had to start a task was the complicated Task.Factory.StartNew. Among its parameters there’s a TaskCreationOptions often used to specify TaskCreationOptions.LongRunning. That flag gives TPL a hint that the task you’re about to execute will be longer than usual.

    Nowadays with .NET 4.5 and above we mostly use the simpler and safer Task.Run but it isn’t uncommon to wonder how do you pass TaskCreationOptions.LongRunning as a parameter like we used to do with Task.Factory.StartNew.

  • May 16, 2015 | async-await, Bugs | comments | Edit
  • LogicalOperationStack Is Broken With async-await
  • Trace.CorrelationManager.LogicalOperationStack enables having nested logical operation identifiers where the most common case is logging (NDC). Evidently it doesn’t work with async-await.