I was wondering if there are benefits associated with using a BufferBlock linked to one or many ActionBlocks, other than throttling (using BoundedCapacity), instead of just posting directly to ActionBlock(s) (as long as throttling is not required).
相关问题
- Sorting 3 numbers without branching [closed]
- Graphics.DrawImage() - Throws out of memory except
- Generic Generics in Managed C++
- Why am I getting UnauthorizedAccessException on th
- 求获取指定qq 资料的方法
If all you want to do is to forward items from one block to several others, you don't need
BufferBlock
.But there are certainly cases where it is useful. For example, if you have a complex dataflow network, you might want to build it from smaller sub-networks, each one created in its own method. And to do this, you need some way to represent a group of blocks. In the case you mentioned, returning that single
BufferBlock
(probably asITargetBlock
) from the method would be an easy solution.Another example where
BufferBlock
would be useful is if you wanted to send items from several source blocks to several target blocks. If you usedBufferBlock
as an intermediary, you don't have to connect each source block to each target block.I'm sure there are many other examples where you could use
BufferBlock
. Of course, if you don't see any reason to use it in your case, then don't.To add to svick's answer, there is another benefit of bufferblocks. If you have a block with multiple output links and want to balance between them, you have to turn the output blocks to non-greedy and add a bufferblock to handle the queueing. I found the following example useful:
Quoted from a link that is now dead:
This is what we are planning to do:
Note, that BufferBlock does not handover copies of the input data to all the target blocks it is linked to.Instead it does so to one target block only.Here we are expecting that when one target is busy processing the request.It will be handed over to the other target.Now let’s refer to the code below:
When executed it produces the following output:
This shows that only one target is actually executing all the data even when it’s busy(due to the Thread.Sleep(100) added purposefully).Why?
This is because all the target blocks are by default greedy in nature and buffers the input even when they are not able to process the data.To change this behavior we have set the Greedy property to false in the DataFlowBlockOptions while initializing the ActionBlock as shown below.
The output of this program is:
This clearly a distribution of the data across three ActionBlock(s) as expected.
No, the second example won't compile for a number of reasons: It's only possible to set greedy=false for a "grouping" dataflow block - not for an execution block; and then it has to be set via GroupingDataflowBlockOptions - not DataflowBlockOptions; and then it is set as a property value "{ Greedy = false }" not a constructor parameter.
If you want to throttle the capacity of an action block, do it by setting the value of the BoundedCapacity property of DataflowBlockOptions (though as the OP stated, they're already aware of this option). Like this: