Subject: Re: [boost] GSOC 2015 : Project on Concurrent Hash Tables
From: Amarnath V A (me_at_[hidden])
Date: 2015-03-06 00:59:07
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? What I was
trying to achieve was different. I was trying to get the reference of
_buckets of the old map and give this to the new map. After this was
done, I was just creating few empty buckets and giving it to the old
map. This means that I was hijacking the reference of the buckets that
were being used by some threads and moved it to new map. Looks like
this way of implementation is not right.
>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?
> 2 = this bucket is dead.
Okay. So who takes care of getting rid of the dead buckets?
> 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
> 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.