Intel® Threading Building Blocks

Problems on concurrent_vector with TBB 2.1 by VisualStudio2005sp1 under WinXP SP2

I am currently usingTBB 2.1inVisualStudio2005sp1 under WinXP SP2, with the Intel official VS plug-in for TBB.

I am quite sureI has installed the TBBlibrary and the VS plug-in properly, and I have written some codes with TBB[not containing the concurrent_vector] that compiled and run successfullyin VS. And here is a special case I cannot solve nor can I find any reference from the turtorial or manual. It is playing withpointers to the concurrent_vector, compiled with debug version.

Forums will be read-only from 09/24 10PM PST to 09/25 12PM PST


From Tuesday, September 24, 10pm PST to Thursday, September 25, 12pm PST, the Intel Software Network Community Forums will be read only in preparation for the new forums interface launch on Thursday, September 25. During this time, users will be able to read the forums, but will not be able to reply or submit new topics. The new forums will have an improved look and many added features. We hope youll like the new ISN Community Forums.

Warm regards,

cache_aligned_allocator and small allocations

ive got a cache_aligned_allocator which I use to allocate matrices that are at most 16bytes...

now im unsure how cache_aligned_allocator works with allocations smaller than a cache line...

does it allocate 16 bytes and then add unusuable padding?

or does it allocate as many matrices there is room for in the cacheline and then pads the rest... and then when i allocate another matrix it will actually use one of these "padding matrices"...



TBB uses an approximation of Cilk-style
scheduling (work LIFO; steal FIFO).It has good locality and load
balancing properties while making certain space guarantees. It enables
clean nesting of software components, analogous to the way serial code
composes by nested subroutine calls.

Do scalable allocators work like a deep?

Is scalable_realloc a pool or does it only really grab the small chunk needed?

My applications scales poorly, though each thread is completely independent and work/overhead ratiois significant. It happens to allocate 250K tiny vectors (about 5 pointers in each) in a little under 2 seconds. 16 threads are doing this simultaneously. My test applicationthat performssimilar "work" but does arithmetic in place of all these allocations scales perfectly.

A small bug

I was trying to write a program, where i am using both Intel TBB and ACE(Adaptive Communication Environment). I came across an error, where lot of definitions in winsock.h have found its duplicate in winsock2.h.
Intel TBB includes windows.h in my machine and thereby it includes winsock.h, whereas ACE includes winsock2.h. The only solution, i could find in net is to declare winsock2.h before windows.h.

static library for massively parallel computer

First, thanks to the developers for a very impressive package.

I'm working (unsuccessfully so far) to strip the shared library dependency
out of TBB so that I can use it on a massively parallel computer that does
not support shared libraries (a common situation). Has anyone
succeeded at this or could point me in the right direction?

The issue is how to either remove/replace the dlopen() etc. calls in tbb_misc.cpp or
to provide functional stubs for the dl routines in a static environment.


Allocating an additional child of a non-running task with running children from multiple threads

I have an non running empty task used to synchronize some potentially long running work as suggested by the TBB book.

I don't know how many children tasks I need to create and I need to start running them before they are all created. The TBB book tells me I need to use allocate_additional_child_of(*empty) here.

Larrabee and TBB

Hi, We've been watching Larrabee with a lot of interest, particularly
for general purpose computation. What can we expect with regards to
TBB support? Will it support TBB right out of the box, how does performance look? The SIGGRAPH paper is a bit vague in this respect.
Thanks for any information,


Subscribe to Intel® Threading Building Blocks