On 6 Mar 2015 at 5:01, Rob Stewart wrote:
Say, I performed a move construction of old_map and it was being used by few threads, shouldn't I mark it for reloading by those threads.
This doesn't seem reasonable to me. Move semantics apply to temporaries, not to objects still in use. That applies to concurrent data structures, too. Otherwise, you have to copy the container so the container and its data are not yanked out from under other threads. Obviously, the onus is on the owner of the container to apply move semantics only when safe.
3. How do I handle exceptions in move construction? On an exception, what is the move construction expected to do? Just abort whatever it was doing and restore the old_map?
Exception safety means restoring the map to as if no change had happened with no resources leaked or data changed.
That's only true if you provide the strong guarantee.
concurrent_unordered_map is defined to be a STL drop in equivalent, so everything that unordered_map guarantees is guaranteed by concurrent_unordered_map [1]. Obviously it isn't quite as easy as that - in practice as you remove the locks around your unordered_map usage you will probably find some refactoring will be needed as just because concurrent_unordered_map is threadsafe doesn't mean the code using it is. The big aim was that a single code base with very little #ifdefing could have a macro selectable dual implementation as concurrent_unordered_map isn't as fast as a spinlocked unordered_map on average, but has much lower worst case latencies. And that's a tradeoff, with pros and cons. [1]: There is a slight issue with emplace() in that it doesn't preserve inputs on exception throw. The same problem afflicts some unordered_map implementations too. I think there was a defect before the LEWG about that. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/