Community
cancel
Showing results for 
Search instead for 
Did you mean: 
AJ13
New Contributor I
40 Views

Multiple Concurrent Pipelines

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
40 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.
AJ13
New Contributor I
40 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.
RafSchietekat
Black Belt
40 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.

AJ13
New Contributor I
40 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.
ARCH_R_Intel
Employee
40 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.

AJ13
New Contributor I
40 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
RafSchietekat
Black Belt
40 Views

Add 1 worker thread per pipeline, and perhaps do the connection management in a tbb::thread instead.