The main difference between threads and TBB tasks, is that TBB tasks are scheduled to be executed by one of the threads in the TBB thread pool. If you were to receive many messages and create a boost thread to execute each one, you could potentially have many threads fighting for resources on the cores. If instead, you create a TBB task to process each message, these lightweight tasks would be scheduled on to the TBB worker threads. By default, TBB creates one worker thread per core (or thread context when using Hyperthreading). So you would avoid oversubscription, and since its faster to create a task than a thread, the overhead per message should be lower.

That being said though… if you depend on messages being processed concurrently with the main thread or with each other, then only a thread guarantees that. In TBB, the parallelism is not guaranteed. For example, in your code above it would be possible that the main thread that calls "run" will also be asked to execute the task inside of the call to "group.wait()". Or, it is also possible that a worker thread may execute processA and the main thread will just wait at the “group.wait()”. It all depends on what the TBB scheduler decides to do. So there is no guaranteed parallelism. Often, when the TBB scheduler does not use parallelism it is because using the parallelism would actually result in a slower execution. But if your application requires parallelism for correctness, not just performance, then only threads will suffice.