I'm stuck with a problem I quite don't understand and that involve either boost::future/promise or tbb::concurrent_queue,
or my understanding of using both.
I think there is a high probability that someone here will point to the problem, but I will report too to the tbb forum
Some context:
- I'm using VS2012 Update 2
- it's 32 bit DEBUG mode
- I use Boost.Thread V4 (in CMake I set "add_definitions( -DBOOST_THREAD_VERSION=4 )" to force it )
- I use TBB 4.1 Update 2
Hi All ,
I have written an image processing related code. I used TBB for parallel implementation of computationally intensive for loops. The program runs fine on Linux. I am trying to port it on windows. When I try to build the executable , I get following linker error:
Hi,
Suppose there are some worker objects which contains some internal resource such as socket. Those worker objects are created at the program startup and destroyed at program exit. The main thread will pass an object ID to one of the worker object. Then the worker will process it and send the result throght socket. What I want is those workers run parallely. Is there any of TBB component that can serve for this purpose?
At the moment I am testing some parallel scheduling libraries like TBB, OpenMP, XKAAPI and so on. To get a first quick impression I implemented a naive matrix-matrix multiplication, first for floating point entries, then for uint64 entries. The tests I run on a NUMA with 4 nodes of 8 cores of Intel Xeon CPU E5-4620 0 @ 2.20GHz. Each node has 96 GB of RAM.
TBB 4.1 Update 3 stable release is available for download on our site - tbb41_20130314oss
Changes (w.r.t. Intel TBB 4.1 Update 2):
I want to know what you guys think about the following additions to the interface of some parallel constructs.
I think almost everybody agrees that the interface for std:: algorithms are a bit verbose and that the boost::range algortihms together with their adaptors have a much cleaner interface.
std::vector<int> vec{3, 2, 1};
boost::for_each(vec, some_lambda);
boost::sort(vec);
We could introduce these interfaces to tbb, too.
I encountered a strange problem with enumerable_thread_specific: a enumerable_thread_specific object got deleted prematurely when a root task using it was spawned from a variadic template function (which I added for convenience to a base of the task). See attached code. Tested using gcc 4.7.0 and 4.8 only.
I wonder whether there is a (legal) way to obtain the size of a tbb::task_list.
I would like to write a little template class that implements a continuation task, using CRTP to do the actual work. The simplest way to do this seems to get the size of a tbb::task_list for setting the correct ref_count, see attached sample code.
Btw, wouldn't it be nice if tbb comes with little helper classes like this?
Hi, I am trying to write a Linux device dirver. I want to know whether or not TBB libraries can be used in kernel-space other than user-space?
Thanks,
Paul
Hello everyone,
When using enumerable_thread_specific, it can be useful to specify the parameters that will be used when constructing a new object when a thread requests for one.
Two similar possibilities exist in the current implementation :
