Boost logo

Boost :

Subject: Re: [boost] Request for feedback on design of concurrent_unordered_map, plus notes on use of memory transactions
From: Bjorn Reese (breese_at_[hidden])
Date: 2014-07-30 11:19:59


On 07/27/2014 05:20 PM, Niall Douglas wrote:

> 1. Items in a bucket were kept via an atomic forward pointer to the
> next item and one used cmpxchg to insert and remove items. This had
> really great, even superb, performance for load factors near one, but
> became pathological for badly distributed hash functions (I'm looking
> at you libstdc++). Once you rehashed the hash function to make it
> better distributed, performance nose dived. I was tempted to override
> std::hash with a decent implementation ...

I would not rule out this solution. You can just tell users to supply
their own hash function to solve the distribution problem.

> Final proposed design (comments welcome):

> If value_type has a big sizeof(), a very good idea is to make the
> above a unique_ptr as otherwise you can't pack many item_type's into
> a cache line (AFIO's value_type is a std::pair<size_t,
> std::shared_ptr<>> which is 24 bytes, so item_type is 32 bytes which
> works well for my purposes).

You add storage traits so users can decide for themselves. This
trait would contain the stored type and to/from conversion functions.

> * To insert or find an item involves determining the bucket from the
> modulus of the hash by the number of buckets, locking the bucket and
> scanning the linear list for an empty item or the right item as
> appropriate. We know empty items from a magic hash value which is
> defined to some magic constant (advice on the best magic hash value
> least likely to turn up from std::hash is welcome). find() starts

std::hash already does a modulo operation, so you could simply do
another to free a number for the magic value. For example,

   auto magic = std::numeric_limit<Hash::result_type>::max();
   hash %= magic;

It will change the distribution, however, as as both 0 and max are
mapped to 0.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk