What I like most about Intel® Threading Building Blocks (TBB) library is its incessant evolution. Having been first released almost five years ago and enjoying quite broad adoption in the software development industry since then, it still keeps growing new features at unabated pace.
Master threads isolation described in the first part of the blog was not the only change in the TBB 3.0 scheduler ameliorating composability of the code parallelized with TBB. Another tightening in the scheduler guarantees improves a popular usage model described in the TBB Reference Manual as “Letting main thread work while child tasks run”. Here is a short example of what it looks like:
This is the first of two blogs where I’m going to describe some of the problems that users of TBB 2.2 and earlier came across, and the changes in task scheduler behavior made in TBB 3.0 release in order to solve them. In this part we’ll talk about issues caused by the lack of master threads isolation from each other inside TBB task scheduler. But first off, let me share with you a little of the background considerations.
After a good deal of theoretizing about various cancellation scenarios, we’ve finally reached the point where we can touch a bit more material substance (if one can say so about information☺). So let’s see how to use group contexts in practice.
After the long-winded introduction let’s consider the semantics of task cancellation and exception handling in TBB. The basic usage model of cancellation was shaped in order to cover the following primary use cases:
- Cancelling an algorithm when one of its tasks decides that the purpose of the algorithm has been reached. A variety of parallel search algorithms falls in this category for instance.