Boost logo

Boost :

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

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at