A while ago I usedTBB tasks to implement "longrunning" tasks. Due to the way tasks work such a thread will block one core of the CPU as long as it's running. That's not very good soI'm now going to usetbb_threads instead of tasks.
The tbb_threads will be waiting for information coming from the main program. Previously I used a concurrent_queue for this communication. I have a thin producer-consumer wrapper around theconcurrent_queue whichworked in two modes, one quick response mode for rapid bursts of information, and one slow response mode for long waits while nothing happens. In quick mode the concurrent_queueuses try_pop as long as the queue isn't empty but then it switches to waiting on a mutex when the queue is empty. This part of my solution seems to be working well.
Now my question is, which is the best way to communicate between the main program and a tbb_thread? Is it a good ideatoreuse my concurrent_queue wrapper described above or is there something wrong with this approach? Maybe concurrent_queue isn't a good choise? Will it work at all?Maybethere's a much simpler or smarter or more obvious way to do it?
I really need some good advice here. Thank you.
"I've looked at it but I don't quite know what to do with it."
Well, if it's #define'd as 1, I would presume that at some point a change has been made to avoid busy-waiting in concurrent_queue, which seems to be what you want. The implementation seems to have been changing over time, but from what I remember from glancing at the code earlier it spins a number of times and then blocks.
"It seems to be an undocumented build directive that's not even recommended for use"
That may mean that the previous version is not maintained. At some point the dead code will probably be eliminated.