Typo in get_impl? about high-scale-lib HOT 5 OPEN

Ditto for putIfMatch.

from high-scale-lib.

There are a couple other race conditions as well. If this lib is actively used, I'm happy to report them, but I'd like to avoid typing them up if the effort would be wasted.

from high-scale-lib.

Yes please do, it's in active use in a number of different places.

from high-scale-lib.

Here's the other major "gotcha" cases I found. For reference, my C++ implementation is here and is what we're using in HyperDex now.

The resize method makes a chain of inner tables. Although it's extremely unlikely, it's possible for the recursive putIfMatch call to overrun the stack. I saw this in an application with more threads than cores, where one thread was forced to wait to run. By the time it ran, the other threads had constructed many new tables that the global table had promoted past. These intermediary tables were necessarily filled with tombstones, but the straggler thread would still attempt to resize them using the copy helper. Of course, this copy helper would step down to the next table, and repeat. Eventually it overran the stack. Tuning the table resize rate can significantly decrease the likelihood of this race condition. A more solid fix, that I use in my impl, is to count the resize number at which each inner table was established. Upon entry to the putIfMatch call, I skip ahead to top-most table accessible from the outer hash map. This allows a straggler to always work on a copy of the inner table where it can do useful work, without scanning tables that are definitely fully copied.

I also thought the counter implementation was racy during a resize, but it looks like it's doing the right thing.

from high-scale-lib.

The other issue I forgot about and didn't include was the "clear" call. It doesn't behave well with resizes, especially stacked resizes. I opted to remove it completely.

from high-scale-lib.