On 1 Sep 2014 at 18:53, Vicente J. Botet Escriba wrote:
Dear Boost,
CC: Howard, Jonathan for N3645 enhancements
Is this related to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3732.pdf?
If you're talking about my concurrent_unordered_map, then no I haven't implemented N3732 as that is a "post-STL" map API proposal i.e. such a container would not be STL compatible. My concurrent_unordered_map exactly follows the API of std::unordered_map, with all the same guarantees apart from the complexities of empty() and size(), so iterators work as expected etc. It should be drop in replaceable, and with little to no performance cost in single threaded usage either apart from empty() and size() being expensive. If you're talking about N3645 enhancements, they are different. N3645 adds new functions to the map API allowing one to, with very low overhead, detach items from one map and insert them into another, or to move allocation and deallocation of nodes outside any serialisation, thus enabling very low latency usage of containers shared between threads. concurrent_unordered_map already moves almost all memory allocation outside of locks, and in fact internally is implemented using the N3645 API i.e. insert/erase/emplace are all just convenience wrappers for the N3645 API. Consider N3645 more as a "map fundamentals" API from which the STL map containers can be constructed. I personally found it very valuable, and I would strongly recommend its immediate inclusion into the next Library TR from WG21. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/