Boost logo

Boost :

Subject: Re: [boost] GSOC 2015 : Project on Concurrent Hash Tables
From: Amarnath V A (me_at_[hidden])
Date: 2015-03-10 21:32:22

On Tue, Mar 10, 2015 at 8:28 PM, Niall Douglas
<s_sourceforge_at_[hidden]> wrote:

> Regarding the move constructor, I am surprised you haven't noticed it
> can be written in two lines yet. It wouldn't be particularly
> efficient, but then I didn't ask for the most efficient solution - I
> asked for a solution which works and is correct. This programming
> competency test is actually much smaller than it looks as soon as you
> mentally grok it, and remember that correctness is far more important
> than efficiency.

Niall, I was pretty confused about the move constructor. Sorry that I
could not achieve what is expected.
Anyways, is this the better and right implementation?

      concurrent_unordered_map(concurrent_unordered_map &&old_map)
          typedef decltype(_rehash_lock) rehash_lock_t;
          lock_guard<rehash_lock_t> guard(old_map._rehash_lock,
          buckets_type *temp=new
, memory_order_acq_rel);
, memory_order_release);

Right now, in here I am getting the _buckets from old_map and moving
it over to the new map. I thought this was the wrong way to accomplish
the task. Is this the right approach?

I had just two approaches to the move constructor.

1. Move the buckets as such to the new map. This is what I was trying
to achieve initially. Later from the conversations we had on the
mailing list, I thought the better implementation is to move the items
in the buckets one by one.
2. That is how I thought of the iterating through bucket by bucket and
move the items one by one.

Are these the approaches or is there a better way to get this done.
Once again, I apologize if I couldn't meet the expectations of boost
community out of a prospective GSoC student.


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