In a post a while ago, I talked about sequential composition of asynchronous operations. Now that we have the async/await keywords in C# and Visual Basic, such composition is trivial, and async/await are indeed the recommended way to achieve such composition with these languages.
We’re happy to announce that you can now download an Async Targeting Pack for Visual Studio 11 that lets you target .NET 4 and Silverlight 5. The included DLLs address the previously discussed issue of the Visual Studio 11 Beta compilers being incompatible with the AsyncCtpLibrary* DLLs from the Async CTP;
After my previous post, I received several emails and comments from folks asking why I chose to implement ForEachAsync the way I did. My goal with that post wasn’t to prescribe a particular approach to iteration, but rather to answer a question I’d received…
Jon Skeet recently asked me how I might go about implementing the following “asynchronous ForEach” behavior:
For each element in an enumerable, run a function that returns a Task<TResult> to represent the completion of processing that element. All of these functions may run asynchronously concurrently.
Thanks to everyone who attended my “The Zen of Async” presentation on Thursday at the MVP Summit. As I’ve had several requests, here are the slides and code for the talk.
TPL Dataflow includes a number of built-in, already-implemented blocks that target the most common scenarios. Additionally, some flexibility is provided by the set of options that may be used to tweak block behaviors. However, a developer may still choose to implement a custom block for advanced scenarios where the built-in ones are not sufficient.
In the .NET Framework 4.5 Developer Preview, you’ll find that CancellationTokenSource now has timeout support built directly into its implementation. This makes it very easy to create a token that will automatically have cancellation requested after a particular time interval, e.g.
Available since .NET 4, ThreadLocal<T> is a container that holds a separate value for every thread. In practice, ThreadLocal<T> is often convenient for storing per-thread counters, resources, or partial results.
As mentioned earlier on this blog, we have been thinking about adding a Values property to enumerate over the values from all threads that ever stored a value into the ThreadLocal<T>
One interesting thing to know about PLINQ is that not all queries are guaranteed to execute in parallel (See PLINQ Queries That Run Sequentially for reference). You can think of the AsParallel method as a hint to run in parallel for query shapes that it believes will be faster.
Imagine that you have a Task handed to you by a third party, and that you would like to force this Task to complete within a specified time period. However, you cannot alter the “natural” completion path and completion state of the Task,