Given the nice simple definition of the container ( "hashed associative container that can be used without synchronization from multiple threads" ) , I believe find_and_visit should synchronise despite the breaking the "C don't pay for what is not used" mantra. Unless, of course, two functions are provided. Keith Burton Peter Dimov wrote:
A preliminary documentation for a concurrent_hash_map is available:
http://www.pdimov.com/cpp/concurrent_hash_map.html
There exists a prototype implementation for that :-) and I'll post it online after a bit of cleanup.
I have a question on the interface that hopefully may be of interest to someone. concurrent_hash_map implements the following member function:
template<class F> bool find_and_visit( K const & k, F f );
that looks up the element with a key k in the map and, if found, invokes f on its associated value. This can be useful in a number of situations, but it poses the following problem: what if two threads call find_and_visit at the same time with the same k and f modifies its argument? Should the map serialize the two calls to f, or should it leave the responsibility of ensuring proper synchronization (or atomic update, if the mapped_type allows it) to the user?
Thanks in advance for any comments/opinions on the interface.