Intel® Threading Building Blocks

is it reasonable to use thread_bound_filter

The use case is:

  There are global shared buffer among different stages, and I employ flag array to control accesses  to these buffers from different stages, which are usually the fi and fi+1 (producer and consumer)。

  tbb::atomic<int> BufIsFull[N];

tbb::atomic<unsinged int> WriteToBufNum, ReadToBufNum;

  Now, because the filter(serial) can be executed by different threads on different items, so I  have to make these flag array and index variable to these array are tbb::atomic(WriteToBufNum, ReadToBufNum).

how to install? how to use concurrent_bounded_queue under Windows / VS2012?

I'm completely newbie to TBB, i want to use "concurrent_bounded_queue" in my application (i do not plan to use any other parts of TBB if this matters)

I've downloaded and extracted TBB, now I have tbb43_20140724oss folder on my PC.

What next steps should I do to use "concurrent_bounded_queue"  from VS2012 (MS VC++ compiler)?

problem about concurrent_priority_queue order

I want use TBB concurrent_priority_queue in my program. so I did some tests
insert 6 elements with different priority into queue.
job priority
------------------
job0   2
job1   0
job2   1
job3   0
job4   2
job5   1

when pop them one by one, The result is supposed to be job1 3 2 5 0 4. the actual result is 1 3 5 2 0 4
two of them seems not follow FIFO rules. same result in many times test.

Serial vs Parallel with hashmap & pipeline: discrepancy

Dear all,

I'm porting another simple I/O intensive piece of code to TBB, but my two versions differ hugely in their results. The serial version uses a unordered_map of strings to ints, and the parallel one accordingly uses a concurrent_hash_map. The pipeline reads strings, and counts them concurrently, as you will see, making use of std::atomic.

The serial code is as follows:

tbbmalloc privatizePublicFreeList appears to have an inifinte loop bug

 

One of our customers is hitting a deadlock condition in our application where a lock is being held forever by one of our application threads.  I have taken a memory dump of the application while deadlocked, and I believe I have traced the problem to an infinite loop in the tbbmalloc dll.  Here is the stack trace:

New Book, features TBB: Multithreading for Visual Effects

I have a copy of my latest book (with 6 wonderful co-authors)!  Based on the SIGGRAPH tutorial we did last year, it reviews successful techniques for parallel programming in applications doing visual effects (think: animated movies!)  The most referenced technique is TBB although other methods including OpenCL are also discussed.

Recursive depth-first TBB usage?

I have a vector of objects on which I need to run a function in parallel. Each task involves a recursive octree traversal, and I'm curious if there is a better way to organize my TBB usage to get more optimum depth-first parallel traversal.

Right now each tree node uses a blocked range parallel_for to start the recursion into each tree. Each of the function calls that kick off the tree-traversals are also called using a blocked range parallel_for.

Details about bugs fixed

Hello,

I would like to know details about bugs fixed.
More specifically, I would like to know more details about the following fixed at the TBB 3.0 update 3.

- Fixed a data race in task scheduler destruction that on rare occasion could result in memory corruption.

What should I do for getting to know details about it?

I appreciate your help.
Thanks.

Subscribe to Intel® Threading Building Blocks