In my blog at http://softwareblogs.intel.com/2008/07/02/implementing-task_group-interface-in-tbb/, I posted a TBB implementation of Microsoft's proposed task_group interface. I'd be interested to hear whether people find it useful or not.
I'm writing a benchmark making use of tbb tasks spawned largely with the "allocate_additional_child_of(...)" command, due to not knowing how many tasks to spawn until runtime. Currently I performan set_ref_count(1), then in a loop perform as many allocates and spawns as necessary, then doing a wait_for_all. This seems to run fine for small numbers of tasks, but if I start getting into larger values (thousands), I begin to get random assertion failures, the most common of which is "another thread emptied the return_list."
Is there any plans to addpointer containers like boost ptr_vector? It would be better than storing a referenced counted smart pointer.
I am evaluating TBB (so far only parallel_for) for possible use in our application.
So far, I am very satisfied with the results, but I have a few questions:
1. Since our application runs in real time, and has high demands on reliability, we
have a general rule that memory allocation/deallocation on the heap is forbidden during
run time. I have tried to read the soruce code (task.cpp), and as far as I could see,
TBB obeys this rule in the sense that parallel_for can cause memory to be allocated
What's the current status regarding the support of the MinGW compiler under win32? I've just checked the release-notes of TBB 2.1 for Windows and there is no mention of support to this compiler.
is there a maximum number of children that a parent task can spawn? i'm running into the following problem.
i'm recursively spawning tasks. the root task appears asserts consistently when it tries to spawn the 0x57 (87) task. the assert i get is:
tbb::assertion_failure (filename=0x2a96099170 "../../src/tbb/task.cpp", line=0x505, expression=0x2a96099e8c "t->state()==task::allocated", comment=0x2a96099e54 "attempt to spawn task that is not in 'allocated' state") at ../../src/tbb/tbb_misc.cpp:65
I've been reading "The Art of Multiprocessor Programming" which seems to have nothing but good things to say about atomic operations. They sound nice, but as a pessimist I did a benchmark today (the code is at the bottom of this post).
I'm working on moving some legacy code that we have over to parallel algorithms. I've run across a weird one today that will work well with a parallel scan, however the "Initial Scan" is much simpler than the "Final Scan" and I'm wondering if TBB will handle that well. Generally, from what I've found in the docs, a the initial and final scan in a parallel scan do about the same amount of work/take the same amount of time. E.g., in a cumulative sum, the initial scan calculates the running sum and the final scan calculates the running sum and stores it.
I've started to explore TBB 2.1.
The following code doesn't work (no output generated), although strace -f shows a new thread is created. What's wrong here? Is stdout not shared with the parent process or something?
std::cout<< "Hello" << std::endl;
int main(int argc, char** argv)
// Is this neeed?