That's a very scary title... especially since it's not true: TBB does what it was designed to do (see below). Please be more careful next time!
Note that you're leaking task_scheduler_init (just make it an automatic variable instead).
Please have a look, e.g.,at thread "Can I separate task::spawn_root_and_wait() into 2 calls?" (it's not the only one with the same subject matter, and if I recall correctly the book also deals with it), and use it/them as an example for your main() function.
Because you are requiring concurrency from a toolkit designed for optional concurrency, it seems that you will have to initialize task_scheduler_init with "std::min(2,default_num_threads())" to get what you want (consider it a hack), butthis will also disableany optimisations for single-threaded execution. Otherwise use an explicit tbb_thread.
Take the following code for example, I want the maintask working parallel with the child task, the maintask spawn the child task and then goes down to do its following job and doesn't wait for its child task finish. The child task should execute while the maintask goes down, this means the maintask and the child task are doing their jobs together. At the end of the program, the maintask will check whether the child task finishes or not, if the child task is still running, the maintask will wait for it finish.The example requires concurrency, and moreover itappears to usefunctional decomposition. Explicit threading (e.g with thetbb_thread class) is the best fit.
Alexey Kukanov: "Explicit threading (e.g with the tbb_thread class) is the best fit." It does have the advantage of not being a hack...Note that neither approach will actually guarantee concurrency yet, but I understand that this will be addressed in an upcoming version (see discussion about pipelines getting all tangled up).