I've realized that I can parallelize my application without resorting to tbb_thread, if I were able to execute multiple tbb::pipelines concurrently. I don't see that this is possible without tbb_thread. Any suggestions on how I can have multiple pipelines running at the same time, each of which have starting filters that block for input? Is it really so easy as to using tbb::tasks which will run the pipelines (I suspect this will block the worker threads).
The question is: if I to call two separate pipelines via pipeline::run() in two tbb::tasks, is that a good idea, or will the worker threads block? Assume that the tbb::pipeline instances will not terminate, and blocking I/O is being performed within them.
I saw in the FAQ it said using tbb::task is okay, but I would think that would block the worker thread.
It's perfectly all right to run pipelines concurrently: that's what recursive parallelism is all about, creating more parallel slack. Blocking is bad, though, and two blocking pipelines means two worker threads not available all the time, so you have to compensate for that.
I thought that I was being clever by using pipelines to avoid explicit threading. Knowing that N stages of the pipeline will block, is it a matter of adding N worker threads to TBB? I would imagine this could lead to over subscription.
In my application, I will be using two tbb::pipelines. One will handle connection details, and the majority of the time it will be blocked waiting for something connection-oriented to happen.
Another pipeline will handle incoming requests, some of which will represent work to be completed in parallel. The first filter of this pipeline will spend the majority of its time blocked, waiting for new input. The end filter of the pipeline will spawn a new tbb::task before returning, and a very large amount of work will then be given to TBB to be completed.