Tpl Dataflow (block structure) – Part 4

2011/12/16

Tpl Dataflow (block structure) – Part 4

this is the 4th post in the Tpl dataflow series, you can see other post in this series at the TDF tag.

this post will discuss a general implementation of built-in Tpl dataflow block.

in general built-in blocks fall into 3 categories

  • Pure buffering blocks:
    present different strategy of buffering and distribution.
  • Execution blocks:
    manipulate the incoming messages.
  • Grouping blocks:
    deal with different strategies for combine messages from multiple sources.

as a test case I will discuss the most basic target block called ActionBlock<T>.

the action block is an execution block which enables the execution of a delegate to perform some action for the datum of each input message.

the following code demonstrate basic action block:

Code Snippet
  1. var ab = new ActionBlock<int>(i =>
  2. {
  3.     /* Do some processing*/
  4.     EventLog.WriteEntry("App", i.ToString());
  5. });
  6.  
  7. ab.Post(1);
  8. ab.Post(2);
  9. ab.Post(3);

all the built-in blocks construct from one or more internal buffer for the input message and one or more tasks (by default single task) which process single message each time.

action block internal is built form a single internal buffer and a task (by default single task) which will fetch single a message each time and invoke the delegate with the message datum.

TDF, TPL, Dataflow, block, action, ITargetBlock, ISourceBlock

it is important to understand that the dataflow blocks release the internal task whenever the internal buffer become empty. then whenever new message reach the internal buffer the block create a new task.

as I said in previous posts Tpl dataflow were design to deal with immense throughput and it try to avoid over subscription.

both the idea of using buffering instead of creating task per message and releasing the task whenever it doesn’t needed anymore lead to better usage of the CPU and memory resources.

Summary

action block is a very simple one. the focus of this post was to present some of the ideas behind the built-in block construction in general.

it is essential to understand the idea of single task (by default) over internal buffering, when you start interacting with the blocks. the behavior of the entire blocks ecosystem (when we chain blocks into more complex flow) will be depend on how each block buffering and execution were configured.

I will survey different configuration option on latter posts.

in the next post I will speak on the block life-time management.

Shout it

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>