At //BUILD/ in September, we blogged about the wealth of new support available for parallelism in the .NET Framework 4.5 Developer Preview. Since then, we’ve been hard at work on the .NET 4.5 Beta. With the beta just released, here are a few interesting and related things that are new or have changed since the Developer Preview related to parallelism and asynchrony.
In my last past, we looked at building an AsyncLock in terms of an AsyncSemaphore. In this post, we’ll build a more advanced construct, an asynchronous reader/writer lock.
An asynchronous reader/writer lock is more complicated than any of the previous coordination primitives we’ve created.
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,
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,
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.
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.
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()),
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.
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,
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,