Re: [boost] GSOC 2015 : Project on Concurrent Hash Tables

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

On Tue, Mar 10, 2015 at 8:28 PM, Niall Douglas
<s_sourceforge_at_[hidden]> wrote:
> I think you may still be trying to copy and paste parts of the
> existing implementation into something which works rather than
> creating your own implementation based on a sufficient understanding
> of how the algorithm works.

Yes, I was heavily relying on the existing implementation. I will
rework and see if I can come up with better implementation myself.

>
> Here's what I would suggest: get a whiteboard or equivalent and try
> drawing out the sequence of an insert operation on the left and an
> extract operation on the right. If you move the left up and down
> relative to the right, you can see how the concurrency can create
> problems if the sequence is not exactly in the right order.
>
> From there, try to write out what a whole container copy operation
> must do, again with an insert and extract operation on the other side
> and you moving it up and down to see concurrency problems. It will
> yield several design choices: Should the copy be a snapshot i.e. no
> concurrency at all? Should the copy allow concurrency with rehashing?

Sure, I will sit down and think about the concurrency issues that will
be faced when insert and extract operations are happening
simultaneously.

>
> BTW you might want to pull updates from the Boost.Spinlock git repo.
> I tried to get the thread sanitiser to not crash out during the unit
> testing over the weekend by trying to workaround a false positive it
> finds in _rehash() which is currently suppressed. The suppression
> means the sanitiser uses a lot of RAM, and it dies. Unfortunately I
> failed to achieve a workaround, but maybe the commented out printf's
> might be a hint to you as to how to go about debugging your
> implementation.
>

I will pull the latest code from the repo.

Thanks,
Amarnath