safe iteration of concurrent_hash_map

safe iteration of concurrent_hash_map

The comments in the file concurrent_hash_map.h indicate that using iterators, begin(), and end() are not thread safe. What is the recommended way to iterate the items in a concurrent_hash_map in a thread safe way? If the answer is "put a mutex around the code that does the iteration" then I also have to put a mutex around find/insert/remove, which sort of defeats the concurrency. I need a way to access all of the elements in the hash map read only - I don't need to modify the elements or remove them during the iteration.

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You could read the manual, or search this forum. "How to lock the whole concurrent_hash_map not warping a portion of code with mutex?" is a very recent thread dealing about a suspiciously similar issue.

Thanks. I was using tbb 2.2 2.20090809 in Red Hat Enterprise Linux EPEL (Fedora) 6 which does not have concurrent_unordered_map. I see that there is tbb 3.0 in more recent versions of Fedora which has concurrent_unordered_map.

Maybe you could disable the package that comes with your distribution and install a more recent one directly from Intel?

Can you give me an code example to show how to do safe iteration of concurrent_hash_map? Document "How to lock the whole concurrent_hash_map not warping a portion of code with mutex?" just can't be opened now.

It would seem that that other thread contained the suggestion to use concurrent_unordered_map instead.


If you can afford not using erase(), concurrent_unordered_map is the best choice. Otherwise, there is a hackish way to traverse concurrent_hash_map if certain constraints are preserved:

Leave a Comment

Please sign in to add a comment. Not a member? Join today