The Intel TBB team is happy to introduce the use of Community Preview (CP) features into Intel TBB today. CP features are a great way for Intel to show new and interesting capabilities to our community and customers before they have been finalized. As part of our commitment to openness with all of the Intel Parallel Building Blocks technologies, we want our users to know what we are working on to make Intel TBB better. We also want to gain your feedback on upcoming features so that we can make sure we continue to meet your needs today and in the future.
These features are fully tested but are not officially supported or necessarily fully documented. Given the early nature of these features, we dont guarantee that they wont be removed or modified in ways that break compatibility with pre-production versions. In addition, they are turned off by default so they wont impact your application unless you want to give them a try. We look forward to hearing your response in the forum to our first CP feature, the Concurrent Priority Queue included in Intel TBB 3.0 update 4, and to the use of CP features in general.
You can easily wait for items become available in a priority queue with an eventcount:
Currently it sits in tbb/src/tbb/concurrent_monitor.h
We think we should not add a blocking pop. Here is why (courtesy Arch Robison):
A busy-waiting pop causes unacceptable performance issues. A properly blocking pop adds much complexity, and adds overhead for users who do not need it. Replacing busy waiting with proper blocking is generally hard to do, unless you put mutexes/condition-variable operations on the hot paths. To keep mutexes/condition-variables off the hot path, you end up needing something like concurrent_monitor.
Our position (significantly influenced by Microsoft's PPL) now is that synchronization for waiting should be done in the application, not in the container. Thats why tbb::concurrent_unordered_map has no blocking operations and tbb::concurrent_queue was revised to remove those.