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

Subject: Re: [boost] GSOC 2015 : Project on Concurrent Hash Tables
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-06 08:30:44

On 6 Mar 2015 at 11:29, Amarnath V A wrote:

> On Fri, Mar 6, 2015 at 9:49 AM, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> >
> > You had the situation inverted. New buckets are normally locked (1)
> > until the copy/move is complete. Old buckets, shortly to be emptied,
> > are locked to mark death (2) and stay that way forever.
> 
> Yeah I get that. But when I perform a move construction, should I need
> to create new buckets and copy items from the old map?

Move construction of the map != move construction of the buckets.

> From your reply, I understand what I was trying to is not the correct
> way to implement move construction. Ideally, should I create new
> buckets and pick items one by one from the old map's buckets and copy
> it? And while doing it, like you said, I will be marking the new map's
> buckets as locked (1) and after this process is complete, I just go
> ahead and mark all buckets of old map as dead (2)? Is that right?

You make new buckets, but move the items.

> > 2 = this bucket is dead.
> 
> Okay. So who takes care of getting rid of the dead buckets?

Old buckets go into a fixed size ring buffer, and get deleted 
eventually.

> > That was my sloppiness on the CI config, sorry, I was running the
> > wrong version of GCC. Fixed now.
> 
> So, if "-fsanitize=undefined" a correct flag? I am also getting the
> same compiler error. Could you let me know which version of gcc should
> I use?

undefined sanitiser is >= GCC 4.9.

You don't need the undefined behaviour sanitiser, though it helps.

As the unit tests use OpenMP, you'll need clang 3.7 or higher which 
hasn't been released yet.

> > You need to set the TSAN_OPTIONS environment variable to the
> > suppressions file like this:
> >
> > export TSAN_OPTIONS="suppressions=tsan.supp history_size=7"
> >
> > Obviously adjusting the path appropriately. You then run the
> > unittests_sanitise binary. The unit tests should execute very slowly,
> > but hopefully no errors appear.
> >
> I will try this out and let you know later.

I see the CI segfaulted last night on this test. I assume it ran out 
of RAM, so I'll tune that later today. history_size may be too big 
now.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/