Módulos Intel® de subprocesamiento

On-going task streams.

We have a couple of applications which all share the same basic task model, and we are struggling to get TBB to behave as desired.  In this model we want to dispatch tasks on an on-going basis, potentially “forever” (i.e. until the machine or software fails) but with the capability to reach the end.  In other words we have a stream of tasks, and they are all fire and forget... except for the need to wait for them all to finish at the end.  Sometimes tasks will want to spawn more tasks as part of the same stream.

How can I know whether a mutex is locked or free?


I am implementing a function that the thread need to know the state of the mutex(i.e. locked or free). But I find that TBB mutex does NOT provide such a function interface. 

There is a function named "bool M::scoped_lock::try_acquire(M&) " providing a similar action but it can acquire the lock on it if the mutex is free. I just wanna know the state of the mutex rather than acquire the lock on the mutex if it's free.

Can someone help me? How can I achieve my goal? Thanks!



Find cores of thread


I'm new to TBB. I have a file reading function. It reads the files and fill into the structure passed as parameter to the function. I have a file X and when it is read, it takes nearly ~15 secs. I'm trying to read 4 times in a for parallel_for loop. I was expecting each read operation will be in a separate thread, and each thread will be in a different core [ my system has 12 physical cores and 24 logical cores ] , so it should be ~15 secs.

If I read it in normal for loop for 4 times, it takes ~57 secs. When I read in parallel_for ,it takes ~41 secs.

Getting TBB allocators to release cached memory

I am using the latest Windows Intel TBB 2018 Update 2, and am struggling getting the TBB allocators to release memory.
My application has a peak usage of say 25GB.

When using the tbb::allocator the "working set" will peak to 25GB and stay there as , even when all objects are deallocated.

When using the std::allocator the memory will also peak to 25GB but will drop back down to the expected level of 2GB when all objects are deallocated.

'tbb::filter': no appropriate default constructor available

Using the latest version of TBB (2018 update 2), when compiled using cpp17 I'm getting the compile error

tbb::filter': no appropriate default constructor available. My class derives from filter, 

class CMyClass : public CMyOtherClass, public tbb::filter

And using it on another class

class cDifferentClass


CMyClass* pInput;

int process()


tbb::pipeline pipeline; // create pipeline





Suscribirse a Módulos Intel® de subprocesamiento