A Message Graph Example
Figure 3 shows an Intel Threading Building Blocks flow graph that implements a simple feature detection application. A number of images will enter the graph and two alternative feature-detection algorithms will be applied to each one. If either algorithm detects a feature of interest, the image will be stored for later inspection.
In the figure, a
src, supplies images to a reserving join node,
resource_join. The second input of
resource_join is connected to a queue of image buffers,
source_node only generates new items after its current output has been consumed. A reserving join node does not consume incoming items until it can reserve an input at each of its incoming ports. The front of this graph is therefore nicely constructed to control memory use. New images will only be generated by
src if an image buffer is available in
buffers to pair with it.
Once an incoming image is paired with a buffer, it is forwarded to the
function_node preprocess_function, which preprocesses the image, placing the results in the associated buffer. The
preprocess_function may be created with unlimited concurrency, allowing it to process multiple images concurrently. In a feature-detection application, this preprocessing might, for example, include algorithms for blurring the image.
The output of
preprocess_function is connected by an edge to
detect_B, which implement two alternative algorithms for detecting the feature of interest in the images. Again, these nodes may be created with unlimited concurrency, allowing multiple images to be processed by each node concurrently. The outputs of these detection nodes are forwarded to a tag matching join,
detection_join. A tag matching join pairs items together based on matching tags; in this case, it will pair the outputs of
detect_B based on the image they were processing. Use of a tag matching join is important here because multiple images may be in flight in the graph simultaneously, and it's important to match the proper results together.
Finally, a pair of results reaches the
function_node decide. It inspects the results from each algorithm to see if the feature might be present in the image. If so, it stores the image for later inspection. When
decide is complete, it returns the buffer to
buffers so it can be paired with another incoming image.
A complete description of this example and complete source code can be found in "A feature-detection example using the Intel Threading Building Blocks flow graph."
Choosing Between a Flow Graph, Pipeline, or an Acyclic Graph of Tasks
While the flow graph adds significant functionality to Intel Threading Building Blocks 4.0, some applications suited to the flow graph can be implemented using the existing low-level support for acyclic graphs of tasks and the generic
parallel_pipeline algorithm. Table 1 compares these different features and provides characteristics that may help in selecting the most appropriate model to use .
Intel Threading Building Blocks 4.0 includes flow graph as a fully supported feature. A flow graph can be used to express static and dynamic dependency graphs, as well as reactive or event-based graphs that respond to and pass messages between computations. You can learn more about this feature and download the Intel TBB 4.0 library here.
 As a Community Preview feature, the flow graph was named "graph." Intel now use the name flow graph to emphasize that this feature expresses the control flow in an application. The more generic name graph falsely implied a more data-structure centric approach and a collection of classical graph-based algorithms.
or_node are Community Preview features in Intel TBB 4.0.
 Refer to the Intel optimization notice for more information regarding performance and optimization choices in Intel software products.
Michael J. Voss, Ph.D., is a software architect for Intel Corp.