Pipeline/Tasks Internal State similarity to ACE

[Derek_Baikie]

hi I am new to TBB; but a little familiar with ACE (Stream/Tasks).

With ACE I have developed ACE_Streams (seems equivalent to Tbb Pipeline).In ACE, ACE_Tasks are not spawned, but reused.As such, the Tasks are able maintain internal private state (eg a running total).

My question is does Tbb support filters within a pipeline which are not spawned and as such can maintain internal state - if so if there an example? If not, is there a best practiseapproach to dealing with such issues?

If not

[Anton_Pegushin]

Quoting - Derek Baikie

hi I am new to TBB; but a little familiar with ACE (Stream/Tasks).

With ACE I have developed ACE_Streams (seems equivalent to Tbb Pipeline).In ACE, ACE_Tasks are not spawned, but reused.As such, the Tasks are able maintain internal private state (eg a running total).

My question is does Tbb support filters within a pipeline which are not spawned and as such can maintain internal state - if so if there an example? If not, is there a best practiseapproach to dealing with such issues?

If not

Hi, in TBB filters are not spawned, for each stage in a pipeline one filter exists and if the filter is "parallel", then it's operator() (void*) can be called concurrently for different tokens. If the filter is "serial", then it's operator() can be called only serially (possibly from different threads though). So if I understand your problem correctly, all you need to do is guard the filters "state" access from operator() of parallel filters.

[robert-reed]

Quoting - Anton Pegushin (Intel)

Hi, in TBB filters are not spawned, for each stage in a pipeline one filter exists and if the filter is "parallel", then it's operator() (void*) can be called concurrently for different tokens. If the filter is "serial", then it's operator() can be called only serially (possibly from different threads though). So if I understand your problem correctly, all you need to do is guard the filters "state" access from operator() of parallel filters.

Anton, it almost sounds like Derek is asking for thread-local-storage for the pool threads.

Derek, tasks in TBB are not persistent; they are created, queued (often) and executed. Though some may be recycled through continuation tasks, there are not a fixed set of tasks associated with the pipeline filters that might serve as accumulators. Usually such "reduction" operations are handled in TBB via parallel_reduce.

However, the threads comprising the workers that process the tasks in TBB are persistent, and if the pipeline interface is a requirement for your data input, I could imagine an interface in which a filter has thread local storage, available in the current OSS distribution as enumerable_thread_specific, where the filters did accumulation of data in such a thread private area. Of course, you'd need to ensure the private accumulators are initialized before the pipeline is executed and they would need to be harvested once the pipeline was compete. I think you could probably come up with a solution via this approach, though it would be much simpler I suspect if you can just use parallel_reduce.

[Alexey-Kukanov]

Quoting - Derek Baikie

hi I am new to TBB; but a little familiar with ACE (Stream/Tasks).

With ACE I have developed ACE_Streams (seems equivalent to Tbb Pipeline).In ACE, ACE_Tasks are not spawned, but reused.As such, the Tasks are able maintain internal private state (eg a running total).

My question is does Tbb support filters within a pipeline which are not spawned and as such can maintain internal state - if so if there an example? If not, is there a best practiseapproach to dealing with such issues?

If not

Let me add my 5 cents :)
For filter-specific accumulators (which I, like Anton, presumed from the initial post), you may use filters as Anton suggested.
For thread-specific accumulators, which Robert presumed, I would suggest to consider the enumerable_thread_specific class available inrecent developer updates. It will be available in a stable or com-aligned release later this year. Of course Robert's suggestions are up to the point as well.