TPL Dataflow CTP Refresh

Stephen Toub - MSFT

Today, we released a new CTP of TPL Dataflow, otherwise known as System.Threading.Tasks.Dataflow.dll.  You can download this as part of the Microsoft Visual Studio Async CTP, which will also install the new C#/Visual Basic support for writing asynchronous methods, or you can install the DLL itself through the installer available on the DevLabs site.

This new version of the CTP includes a plethora of new features and design changes since the last CTP, many of which were inspired by your feedback and requests:

  • The source and target interfaces are now co/contraviarant.  For example, you can now connect a BufferBlock<Giraffe> to an ActionBlock<Animal>.
  • ToObservable and ToObserver extension methods have been added.  This enables direct integration between TPL Dataflow and Reactive Extensions, with the ability to expose dataflow sources as observables and dataflow targets as observers.
  • Most of the blocks now support the setting of explicit bounded capacities through DataflowBlockOptions.  For example, you can now construct a TransformBlock<TInput,TOutput> with a bounded capacity of 5, and if the total number of elements in its input buffer, elements currently being processed, and elements in its output buffer is 5, it won’t accept any more messages until elements are removed from its output buffer.  This allows you to construct long, bounded chains of blocks.
  • DataflowBlockOptions now has settable properties.  This means that to set a single option, you no longer have to also specify all options that came before it in the constructor’s parameter list.  Additionally, the options have been split into a hierarchy of types (e.g. ExecutionDataflowBlockOptions deriving from DataflowBlockOptions), targeting the specific needs of the block being used.
  • The ISourceBlock<TOutput> interface has been separated out into two interfaces, a base interface ISourceBlock<TOutput> that provides the core source block support, and a derived interface IReceivableSourceBlock<TOutput> that also enables direct receiving from a block through TryReceive and TryReceiveAll methods.
  • The DataflowBlockExtensions type has been renamed to DataflowBlock.  This helps to highlight all of the methods on DataflowBlock that aren’t extensions, e.g. Choose.
  • The DataflowMessage<T> class has now been replaced by a DataflowMessageHeader struct, and the source and target interfaces have been updated accordingly.  This eliminates one of the primary sources of allocations in dataflow networks, resulting in fewer garbage collections and better performance in many scenarios.
  • Both WriteOnceBlock<T> and BroadcastBlock<T> now allow the cloning function to be optional (by specifying null).  This leads to better performance if cloning isn’t required.
  • Grouping blocks (BatchBlock, JoinBlock, BatchedJoinBlock) now allow specification of a maximum-allowed grouping count.  These blocks will automatically complete themselves once the grouping count is reached. This replaces the “declineAfterOne” functionality previously exposed through these blocks.
  • ITargetBlock<TInput>.Post has been removed from the interface and is now an extension method on DataflowBlock.  That’s one less method that needs to be implemented by a target block implementer.
  • IDataflowBlock.CompletionTask has been renamed to IDataflowBlock.Completion, and the ITargetBlock.DeclinePermanently method has been moved down to the base interface and renamed to IDataflowBlock.Complete. 
  • IDataflowBlock now has a Fault method, enabling an external entity to complete the block in a faulted state and with a specific exception.
  • ConcurrentExclusiveSchedulerPair now has both a Complete method and a Completion Task, enabling signaling to the scheduler that it won’t receive any more tasks, and enabling awaiting for all of its processing to complete.
  • DebuggerDisplay and DebuggerTypeProxy attributes have been updated / added to enable better insight into the state of the blocks while debugging.
  • Many bug fixes (most of which deal with corner cases around interaction with faulty blocks) and some performance enhancements.
  • An updated, more liberal End-User License Agreement (EULA).

We hope you enjoy! And please keep the feedback coming.  We love hearing from you.


Discussion is closed.

Feedback usabilla icon