I am running into a problem where I get the following error
Assertion t->state()==task::allocated failed on line 544 of file ../../src/tbb/scheduler.cpp
Detailed description: attempt to spawn task that is not in 'allocated' state
My application starts of by spawning a root task and setting it's ref-count to 1, which creates other tasks. All the tasks are stored in a task-pool which is a TBB concurrent_hash_map. The non-root tasks are created using allocate_root and each time it's done, the ref-count of the root is incremented. Each of these non-root tasks do some computation and then send the outputs of that computation to other tasks. Before the output is sent, the task-pool is checked to see it the correct/intended task is available(created using allocate_root). Each of the non-root task is spawned only when all the "inputs" to that task are available and when the execution is done, the ref-count of the root is decremented.
I have checked the task-ID's and task states. I see that for one of the tasks, after it is being created when one of the other tasks tries to spawn it, the state is once 3(tbb:allocated) and either 0 or 2. This is when I get the tbb_assert error. I see that the ref-count of root is correctly incremented/decremented, when the other tasks are created and destroyed.
I was wondering what could be causing this error. Is there a common mistake that I may be making?
I presume you mean that the non-root tasks are created using allocate_child()? Why are the tasks stored in a map (tasks are deallocated after execution unless they are recycled)? Make certain not to spawn any child tasks before creating the last one and having set the final reference count, unless you use allocate_additional_child_of(). Don't send results to siblings, only to parents (you can also set up a directional acyclic graph relationship if you must). Don't second-guess the scheduler by doing your own reference-count decrementing or delayed spawning, because both of these are what is meant to happen for a parent task. I haven't looked at the state specifics. Please reread the documentation with an open mind about how to use its properties, not with the intention to shoehorn the wrong features of TBB into implementing your own preconceived idea of scheduling tasks. And then you'll probably also have to apply recursive parallelism.