.NET’s Task Parallel Library is seeing a tune-up in the soon to be released .NET 4.6. In addition to some helper methods that reduce code, and possibly memory usage, TPL is gaining a solution to a tricky problem with SetResult.
With .NET 4.5 the way you work with the Task class has changed in a subtle but important way.
We briefly interviewed Zlatko Michailov, author of the Guide to Implementing Custom TPL Dataflow Blocks.
Dataflow Blocks are the backbone of the .NET 4.5’s new high performance parallel processing library. And while they offer a lot of functionality out of the box, there will be times when a custom block is necessary. Zlatko Michailov has put together a document outlining the process and many of the traps you may encounter.
Microsoft has been working on ways to improve the performance of parallel applications in .NET 4.5, specifically those using the Task Parallel Library. One of most impressive improvements is reducing the overhead for waiting on 100,000 tasks from 12,000,000 bytes to a mere 64 bytes.
Silverlight’s asynchronous service model forces developers to deal with multi-threading from the very beginning. So it seems odd that Microsoft choose to omit the Task Parallel Library, which is the core of .NET’s multi-threading infrastructure. Fortunately there are options.
In a message passing system there may be times when mutable data must be shared amongst many tasks. In traditional programming this would be handled by a read-writer block, which would allow one writer thread to block all other threads while it updates the shared data. With a technique found in frameworks such as TPL Dataflow it is possible to avoid this.
A new preview of TPL Dataflow has recently been released along with Visual Studio Async. Along with performance enhancements and stronger ties with the Reactive Framework, it is being positioned as a foundation for building actor/agent style frameworks as opposed to a complete solution.
TPL Dataflow is Microsoft’s new library for highly concurrent applications. Using asynchronous message passing and pipelining, it promises to offer more control than thread pools and better performance than manual threading. The downside is that you have to adhere to design patterns that may be unfamiliar to .NET programmers.
The new Async CPT for VB and C# looks like it may actually make it into the core language. But with all the emphasis on multi-core systems, why is Microsoft investing so heavily in syntax for designed specifically for making single-threaded asynchronous programming easier?
In a recent blog post the Visual Basic team let slip an announcement that Visual Basic and C# would be getting a new syntax for asynchronous programming. Built on top of the Task Parallel Library that was introduced in .NET 4, this adds the Async and Await keywords to both languages.
Task Parallel Library, .NET 4.0’s replacement for ThreadPool, got a face lift for beta 2. In addition to performance improvements, it The most important change is probably the new cancellation framework that replaces parent/child relationships with cancellation tokens that can be freely given to logical groups of tasks.