.NET Parallel Programming
All about Async/Await, System.Threading.Tasks, System.Collections.Concurrent, System.Linq, and more…
Latest posts
Building Async Coordination Primitives, Part 6: AsyncLock
Last time, we looked at building an AsyncSemaphore. Here, we’ll look at building support for an async mutual exclusion mechanism that supports scoping via ‘using’. As mentioned in the previous post, semaphores are great for throttling and resource management. You can give a semaphore an initial count of the number of things to protect, and then it’ll only allow that many consumers to successfully acquire the semaphore, forcing all others to wait until a resource is freed up and count on the semaphore is released. That resource to protect could be the right to enter a particular region of code, and the count...
Building Async Coordination Primitives, Part 5: AsyncSemaphore
In my last few posts, I covered building an AsyncManualResetEvent, an AsyncAutoResetEvent, an AsyncCountdownEvent, and an AsyncBarrier. In this post, I’ll cover building an AsyncSemaphore class.Semaphores have a wide range of applicability. They’re great for throttling, for protected access to a limited set of resources, and more. There are two public semaphore types in .NET: Semaphore (which wraps the Win32 equivalent) and SemaphoreSlim (which provides a lightweight counterpart built around Monitors). Here we’ll build a simple async version, with the following shape: p...
Building Async Coordination Primitives, Part 4: AsyncBarrier
Last time, we looked at building an AsyncCountdownEvent. At the end of the post, I highlighted a common pattern for using such a type, which is for all of the participants to signal and then wait for all of the other participants to signal as well. This kind of synchronization is typically referred to as a “barrier,” and often it can be used in a round. Each participant will do some work, then signal-and-wait for the barrier, then do the next round of work, then signal-and-wait for the barrier, and so on.Just as we built an AsyncCountdownEvent, we can easily build an AsyncBarrier.&nb...
Building Async Coordination Primitives, Part 3: AsyncCountdownEvent
In my last two posts, I discussed building AsyncManualResetEvent and AsyncAutoResetEvent coordination primitives. In this post, I’ll build on that to create a simple AsyncCountdownEvent.A countdown event is an event that will allow waiters to complete after receiving a particular number of signals. The “countdown” comes from the common fork/join pattern in which it’s often utilized: a certain number of operations participate, and as they complete they signal the event, which counts down from the original number to 0. When it gets to 0, it becomes set, and all waiters can ...
Building Async Coordination Primitives, Part 2: AsyncAutoResetEvent
In my last post, I discussed building an asynchronous version of a manual-reset event. This time, we’ll build an asynchronous version of an auto-reset event.A manual-reset event is transitioned to the signaled state when requested to do so (i.e. calling Set()), and then it remains in that state until it’s manually transitioned back to the non-signaled state (i.e. a call to Reset()). In contrast, an auto-reset event also transitions to the signaled state when requested to do so, but it then transitions back to the non-signaled state automatically when a wait operation completes due to that ...
Building Async Coordination Primitives, Part 1: AsyncManualResetEvent
The Task-based Async Pattern (TAP) isn’t just about asynchronous operations that you initiate and then asynchronously wait for to complete. More generally, tasks can be used to represent all sorts of happenings, enabling you to await for any matter of condition to occur. We can even use Tasks to build simple coordination primitives like their synchronous counterparts but that allow the waiting to be done asynchronously.One of the more basic coordination primitives is an event, and there are a few of these in the .NET Framework. ManualResetEvent and AutoResetEvent wrap their Win32 counterparts, a...
Potential pitfalls to avoid when passing around async lambdas
One of the really useful capabilities of the new async methods feature in C# and Visual Basic is the ability to write async lambdas and anonymous methods (from here on in this post, I’ll refer to both of these as async lambdas, since the discussion applies equally to both). This allows you to easily get a delegate to represent an asynchronous operation, e.g. Func<Uri,Task<string>> getContentsLowerCaseAsync = async url => { string contents = await DownloadString(url); return contents.ToLower(); }; Async methods in C# and...
When “ExecuteSynchronously” doesn’t execute synchronously
When creating a task continuation with ContinueWith, developers have the opportunity to provide a TaskContinuationOptions enum value, which could include the TaskContinuationOptions.ExecuteSynchronously flag. ExecuteSynchronously is a request for an optimization to run the continuation task on the same thread that completed the antecedent task off of which we continued, in effect running the continuation as part of the antecedent’s transition to a final state (the default behavior for ContinueWith if this flag isn’t specified is to run the continuation asynchronously, meaning that when the antec...
FromAsync(asyncResult, …) vs FromAsync(beginMethod, …)
The Task Parallel Library (TPL) provides a set of “FromAsync” helper methods that create a Task or a Task<TResult> to represent an invocation of an APM method pair, i.e. BeginXx / EndXx. There are, however, two different flavors among these overloads: ones that accept an IAsyncResult “asyncResult” as the first parameter, and ones that accept a Func<…,AsyncCallback,object,IAsyncResult> “beginMethod” as the first parameter. What’s the difference, and why would you choose one over the other?The fundamental difference between the two is in how t...