Re: [boost] [spinlock] concurrent_unordered_map is ready for review

Subject: Re: [boost] [spinlock] concurrent_unordered_map is ready for review
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-09-01 14:29:46

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/