- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Thanks!
AJ
Link Copied
7 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
I saw in the FAQ it said using tbb::task is okay, but I would think that would block the worker thread.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Add 1 worker thread per pipeline, and perhaps do the connection management in a tbb::thread instead.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page