Intel® Threading Building Blocks

Dump of all waiting tasks

Hi,

I'm building a library on top of TBB's task scheduler. From time to time, the library gets stuck, because of some synchronization issus related to tasks or simply because there is something wrong with the way tasks (and the dependencies in the task graph) are created. This usually means that the main thread is waiting for the root task to finish, but that never happens, because dute to some error (in my library), the continuation of the root task is never spawned.

Identifying small tasks

I'm working with a large Linux program that uses TBB in a variety of places throughout the code. When I run "perf top", the top-most function it displays is receive_or_steal_task. That suggests to me that my TBB tasks are too small, which is causing the program to spend too much time looking for new tasks to run. Presuming that conclusion is correct, the hard question: How do I determine, out of the variety of TBB calls in my program, which ones are the too-small tasks?

Thanks,
Bill

parallel_sort out of bounds

I'm using tbb::parallel_sort to sort a vector of about 300,000 elements. This operation happens quite often across several machines and every now and then I get a segfault. I have a vector<Row*> vr and provide my own comparator RowLessThan to parallel_sort to deal with the Row*. I call parallel_sort(std::begin(vr), std::end(vr), RowLessThan()).

Parallel_for with small grainsize gets stuck

Hi,

I have tested my my code with tbb 4.0 and 4.2 and both have same problem. I use Fedora 18 Linux, kernel 3.10.14. Processor is 4 core AMD Phenom II X4 955. Compiler is gcc 4.7.2. Code is compiled with command: g++ -Wall -g  -o stuck -ltbbmalloc -ltbb -std=c++11 stuck.cpp.

Now serial for and parallel for with so large grainsize that one core does all the job works. I.e. program prints twice numbers 0-79. However in the second parallel for the grainsize is 1, program prints nothing and get stuck.

TBB memory leaks when using inside of MFC application

Hello tbb-users / tbb-devs,

Operation system: Windows 7 x64 SP1; TBB version: 4.2.0; Compiler: Visual Studio 2012.

Problem description:

TBB dumps memory leaks on the exit of MFC application. The same code doesn't dump any leaks, when used from simple command line program. It looks like a DLL unload order problem. Due to late tbb.dll unloading the debuger dumps some static variables as leaks.

Can someone confirm this issue? Is there any work around?

Attached to this post you will find the both test applications: command line and MFC.

pipeline and ifc importation

hello.
I have this problem:
I'm implementing an importer from ifc ( an architectural xml open format).
I wish use tbb for sped up the importation.
The bottle neck is the file, is clear , but may be that i can use my four cores:
I get the data from an xml and the data is composed by blocks:
for example column, wall, beam ecc....
Each of these type(column,wall and beam are classes)must be processed differently by a lot of operations and iterations.
The operations are different for each type but for the same type are equals.

pipeline and ifc importation

hello.
I have this problem:
I'm implementing an importer from ifc ( an architectural xml open format).
I wish use tbb for sped up the importation.
The bottle neck is the file, is clear , but may be that i can use my four cores:
I get the data from an xml and the data is composed by blocks:
for example column, wall, beam ecc....
Each of these type(column,wall and beam are classes)must be processed differently by a lot of operations and iterations.
The operations are different for each type but for the same type are equals.

How to use Concurrent Hashmap in my code

Hi

I have a concurrent hashmap defined like this- This is straight from an example in TBB code.

typedef concurrent_hash_map<MyString,int> StringTable;

Now, how do I do the following with it-

(1) Add data to it

(2) Delete data from it

(3) Find a data in it

(4) Update a key pair value

(5) Modify a key pair value ie data

The example uses the hashmap in a for loop where the above are not implemented.

Yours sincerely,

Arvind.

S’abonner à Intel® Threading Building Blocks