CODEWITHSUNDEEP
c++tbb
louis
louis

Reputation: 69

Tbb parallel pipeline inplace modification of tokens

I want to use tbb pipeline to parallelize proccessing of tokens.

But I don't need to deallocate and reallocate tokens during middle filters. Is it ok to simply modifiing it in-place and return it? For exemple I would like to do:

class MiddleFilter
{
SomeClass* operator() (SomeClass* input)
{
input->somevalue *= 2;
return input;
}
}

and call

tbb::parallel_pipeline(nbtoken, someinputfilter 
& tbb::make_filter<SomeClass*, SomeClass*>(tbb::filter::parallel, MiddleFilter())
& someoutputfilter)

SomeClass will be allocated and freed in input and output filter.

Upvotes: 2

Views: 968

Answers (1)

Arch D. Robison
Arch D. Robison

Reputation: 4059

Yes, inplace modification of the object passed to a filter is allowed, and frequently useful when dealing with objects that are expensive to copy. I've done this when parallelizing Bzip2 with parallel_pipeline. As far as TBB is concerned, the pointer "input" in your example is just a value that TBB makes no attempt to interpret.

There's a further trick that I sometimes use to save allocation/freeing in the first/last filters. If the first and last filters are serial filters, and the first filter produces objects of the same type that the last filter consumes, then a circular queue of objects can be used to recycle objects. The buffer needs to be of size max_number_of_live_tokens (first parameter to parallel_pipeline). The first filter can allocate an object by dequeuing; the last stage can free an object by enqueuing it. Start with a queue of max_number_of_live_tokens. The token limit guarantees that the queue will never underflow or overflow.

The neat part is that the circular queue can be implemented using trivial serial code. An array and two pointers for the tail/head suffice. No atomic operations, locking, or memory fences are required. The guarantee of no underflow/overflow implies that the enqueue operation can be implemented by just bumping the tail pointer (and blissfully ignoring the head pointer). And vice-versa for the deque operation. No locking is required since the callers are serial filters. At worse, both the tail and head pointers are bumped concurrently, but independently. TBB will take care of the memory fencing.

Upvotes: 3

Related Questions