map::tree_bins::concurrent_tree_bin: attempt to subtract with overflow about flurry HOT 5 CLOSED

Sure. I'll put together a PR for this and one for #83 when I'm back home. Should work out to fit in tomorrow.

from flurry.

Current best guess for the order of events would be as follows:

• We have a (regular) bin with 1 element, which is the only element in the map (count == 1).
• That element gets removed by thread 1, which is paused before the call to add_count.
• An element for the same key is inserted by thread 2, which also is paused before add_count (note that all the count updates happen outside of the respective critical sections of the corresponding methods).
• Thread 3 now removes this element again, and decrements count to 0.
• Thread 1 gets to run again and decrements count to usize::MAX.
• Thread 2 gets to run and increments count to 0.

As of yet unsure as to why this is be a problem for us, but wouldn't be for the Java implementation. There is a validated boolean in Java's replaceNode which is omitted in our implementation due to match/continue, but I don't see how that would be the culprit.

from flurry.

The Java implementation has all the size information as long, it's possible that they just
allow this. See also their implementation of size, which essentially clamps the actual computed value to between 0 and Integer.MAX_INT. The tree bin test may just be the first to trigger this for us.

It is also possible that the shared counters we don't yet have influence this, there seems to be some kind of contention detection there. There is also this annotation on the counter cells. But I think it is still possible for the computed value to be negative upon call to size, and that they use long just so they can perform bounds checks on int.

from flurry.

That's fascinating... I mean, I suppose we could just move it to an AtomicIsize instead... I guess they decided it wasn't worth the cost to keep the count accurate at all times. Mind sending a PR?

from flurry.

I can confirm that this was fixed by #88 (perhaps unsurprisingly) after having run it in a loop for a while.

from flurry.