Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

Multiple Concurrent Pipelines

AJ13
New Contributor I
440 Views
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).

Thanks!

AJ
0 Kudos
7 Replies
robert-reed
Valued Contributor II
440 Views
Two separate instances of tbb::pipeline can be run concurrently. What you don't want is two threads running the same instance of tbb::pipeline.
0 Kudos
AJ13
New Contributor I
440 Views
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.
0 Kudos
RafSchietekat
Valued Contributor III
440 Views
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.

0 Kudos
AJ13
New Contributor I
440 Views
tbb::pipeline internally manages its own worker threads internally, right? That was my impression.

In my case the first filter and (and some others further down) will be doing blocking I/O. I don't want to block an entire worker thread for that I/O, which can take a long time to complete.
0 Kudos
ARCH_R_Intel
Employee
440 Views

tbb::pipeline creates and spawns tasks like any other TBB algorithm. Hence as for the other algorithms, a blocking operation hogs a worker thread.

tbb_thread should be used for doing work that is blocked most of the time.

0 Kudos
AJ13
New Contributor I
440 Views
Thanks Arch.

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.

Suggestions?

AJ
0 Kudos
RafSchietekat
Valued Contributor III
440 Views
Add 1 worker thread per pipeline, and perhaps do the connection management in a tbb::thread instead.

0 Kudos
Reply