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.
A week ago I started telling about a couple of new helpful features in the TBB 3.0 Update 4 task scheduler, and we talked about the support for processor groups – an extension of Win32 API available in 64-bit edition of Windows 7. The main purpose of processor groups is to extend Win32 capabilities to allow applications work with more than 64 logical CPUs.
Though I wrote my previous TBB task scheduler blog just a few days after TBB 3.0 Update 4 had been released, I ignored that remarkable event, and instead delved into more than two year old past. So today I’m going to redeem that slight, and talk about a couple of small but quite useful improvements in the TBB scheduler behavior made in the aforementioned update.
Though Intel® Threading Building Blocks 3.0 Update 4 that introduces a concept of Community Preview feature has just been released, my today's blog will be about something that happened quite long time ago. One of the recent posts on the TBB forum attracted my attention to the issue of information rapidly becoming obsolete.
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.