Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

Design for a network service

I am writing a network service and considering using TBB instead of the traditional approach to handle threads myself (I'm a TBB newbie).

The service will essentially receive items that will need to be parsed, processed (with potential CPU-intensive calculation (secure hash) being performed on some of them) and then stored in a database.

I'm curious if somebody has suggestions as to which components of the TBB should be used to implement something like this efficiently.

My initial thought was to store the incoming items in a queue, and then pull the items off the queue in a fifo manner (though the ordering isn't important as long as there is no backlog) and process them in parallel.

Since the items will go through stages (parse, calculate, store), a pipeline seems suitable for that. I have been experimenting with a pipeline already, I'm having difficulty understanding how to use it when the input is a stream of data vs. a fixed set of data. If the first filter returns NULL (as would be the case when there is no more data at the moment), the pipeline just ends?

I imagine that this must be common application of the TBB, and was curious if some examples, templates exist for this?

Thank you for any suggestions and help.
0 Kudos
3 Replies
Can't our Network Router emulator example help here?

Hi Vladimir,

Yes, that should definitely help. I will study that later today to see if I can adapt to meet my needs. In the meantime, how would the example need to be adapted so that processing doesn't stop when the queue is empty? It should just wait and continue as soon as there are items in the queue ... ?

Thank you.
To not stop the pipeline if more data are expected to arrive from an external source, the input filter needs to wait for that data. If you already use concurrent_queue as the input source, the easiest way is probably to switch to concurrent_bounded_queue which have a blocking pop() method.

Be aware however that when the pipeline is blocked in the input filter, one thread (the one that started the pipeline) can be busy-waiting. A new flow graph API does not have this issue, and it can be used to build a pipeline as well (though it will require more things to be coded explicitly, compared to pipeline).