Intel® Threading Building Blocks

Build problem using scalable_allocators in VS2005

I'm having trouble when I declare the key type to be const. This works fine for the standard allocator but gives some funny errors with the scalable_allocator. Here's a sample program that fails to compile:

using namespace std;

int main()
typedef int Key;
typedef int Val;

map, allocator > > foo1;
map, tbb::scalable_allocator > > foo2;

typedef const Key cKey;
map, allocator > > foobar1;
map, tbb::scalable_allocator > > foobar2;

return 0;

Task tree with disappearing internal nodes?


I want to make a task tree where the parent nodes exist only to spawn children (they do a little bit of calculation and spawn only certain children). This is for branch-and-bound code with globally-accessible bounds. A tree structure is natural, and the depth-based scheduling is desirable, but there's no reason to keep the parent nodes around once they've spawned their children. If you do allocate_root() and spawn_root_and_wait() on the children, the parent still has to wait for the rootlike-children to finish, right? Is there any other way to do what I want?

Why only dynamic C/C++ runtimes?


I apologize if this is a commonly asked question, but I was not able to find an answer by searching the forums. I am porting an established commercial project to Visual Studio 2008 with the commercial versions of the Intel C++ compiler 11.0 and TBB 2.1, and have run into a snag with TBB's requirement of using only the dynamic versions of the C/C++ runtimes. The project currently relies on a number of other libraries that all use the static runtimes.

Exposing the Task Scheduler

I have been evaluating the use of TBB for quite some time and i have a question about the use
of Task sheduler. As I understand TBB aims at hiding the complexity of threading and task scheduling
from the user completely.So I assume that this is the reason why the Task scheduler is not exposed
extensively to the user.

By exposing the task scheduler, I mean to be possible to define tasks ( by classes deriving from tbb::task
and overriding execute method) and be able to queue these tasks to the scheduler for execution.

For example,

Regarding Installing TBB on Fedora 9 Please Help

I am using Fedora 9 sulphur Kernel verision 2.6.25 on Intel Pentium Dual CPU E2180 @ 2.00GHz. I installed Intel TBB commercially aligned release verisoin

i extracted the tbb20_020oss_lin.tar.gz file and copied the three folders ie, itanium, em64t, ia32
and pasted them in the extracted tbb20_020oss_src.tar.gz folder built it using make command.

Future Class

How might you write a Future class using TBB? ie

class tbb_future
tbb_future(T (*f)()); //call the passed function
T get_value() //get the value and block until computation is finished

ideally get_value will not just spin and can be called by multiple threads...


Adding first filter to pipeline causes DB Assertion error

Adding the first filter (the input_filter) to a tbb pipeline causes this assertion error: pipeline.cpp Line: 346
" Expression: filter_.prev_filter_in_pipeline==filter::not_in_pipeline()
filter already part of pipeline? "

This happens with not just my code, but the filter definitions from the supplied text_filter project, after copying them into my code environment.

Compiling and running the text_filter project by itself works fine. (version: TBB: VERSION 2.1
TBB: BUILD_DATE Sun, 7 Dec 2008 14:18:46)

Scheduler internals questions

After a break for the holidays I'm back and ready for some more scheduler investigations. Thanks to responses from everyone last time I better understand some parts of the code. I would like to ask for some help understanding the role that some components play in the scheduler. I'm looking to understand the big picture of how these pieces fit. What is an Arena? Task proxy? Mailbox? Thanks.

Subscribe to Intel® Threading Building Blocks