Multiple FlowGraph instances

[memaher]

Hi all,

Is it possible to run concurrent, multiple, FlowGraph instances? If so, what would be the best way to execute them? My immediate thought is to spawn 2 threads, then run each flowgraph in a separate thread, checking for termination, etc.

This is a rather weird design case, where I need to parse the same (huge) data stream twice: hence would be buffering to temporary file mid-flow. The two flow graphs would then be pre-file and post-file. Although it is possible to achieve this using a single flow-graph, there are all sorts of issues surrounding the stalling of the graph should all the data not arrive on time: hence why it's desirable to keep things separate.

Any ideas?

Mat

[jiri]

Just like any TBB algorithm, the flow graph should be able to happily run alongside other instances of flow graphs, algorithms, or manually created tasks. You can use different means to launch two graphs in parallel, two threads being one of the options. You could also use parallel_invoke, serve both graphs from a single thread (should be possible, but you have to be careful), or create tasks to run the flow graphs and spawn/enqueue them. These options differ slightly in details, for example what happens once the flow graph finishes or the effects of exceptions. Naturally, the right choice depends on the context.

[memaher]

Thanks Jiri,

One final question regarding this scenario: is there any way to raise the priority of one flow graph over the other (e.g. changing underlying thread priority)?

Under normal circumstances, each of my flow graphs should never be running concurrently, but there may be anomaly cases where they do. In this instance, it would be nice to have the post-file-thread having a slight priority increase over the pre-file thread: this allows one job to finish in preference to the next job starting.

What do you think?

Mat

[RafSchietekat]

Managing priority would require some serious hacking, because worker threads can migrate between arenas, and there do not seem to be any hooks to act at the right time.

(Added) What I wrote above applies to attempts to use thread priorities, so you should generally leave them at normal priority. TBB's alternative is task_group_context priorities, which operate on task trees and should also work across arenas associated with independent application threads (influencing the number of worker threads apportioned to each arena), although there are only a small number of priorities to choose from. Let us know how this works out for you!