Ok, so I have read quite a few of the posts on here about tbb::pipeline, and I think that my application is definitely an candidate for this processing model. Essentially, I receive a very large stream of data from various sensor abilities (7 different types of messages from my sensor, to be exact), and then a variable number of instruments (as few as 5, as many as 500) read that sensor data and produce calculation results. The model flows:
- for the input filter, distinction of in-order and out-of-order has only one practical difference, which is whether the order for subsequent ordered filters will be set at input, or later. It looks like you do not use ordered filters at all in the setup, so making input filter unordered seems fine.
- for the queue question: from what you said, seems it will have a single producer (your other thread) and a single virtual consumer (because since the input filter is serial, TBB threads executing it will not contend). Thus you might benefit from using a queue optimized for single producer single consumer model. I believe Dmitry Vyukov referenced his implementation in the forum. Make sure however that any queue implementation you choose does not require single actual consumer (e.g. by depending onthread-local variables).
-I would also experiment with combining the 2nd and the 3rd filters, to see which way performance is better (since you told the second stage is very lightweight, it might not deserve an overhead of another filter). On the second thought, if the 2nd stage does error checking and can cancel the whole pipeline or throw an exception, it might make sense to separate it from the 3rd one.