Mutex locks are necessary when multiple threads read, write and modify the same value. And order of their actions matters.
At the beginning all bits of a bloomfilter are off (set to 0).
The insert function sets some bit to 1 according to hash_value modulo bloomfilter size.
The race condition may happen very often. But which one thread will set the bit to 1 first does not matter.
The bit will be set to one as a result.
Writing a value involves reading the value. You're just ignoring this, and describing a perfect fallacy. When the different bits that need to be written end up on the same cache lines (let's say, in the same 64 bytes region, and a lot of cache lines can fit in L1) of different cores, you have two different results, both wrong, and one of those will end up in your filter.
You're not seeing the issue because the allocated area is very large, so the probability of updating nearby bits is low, but a low probability just means it will eventually happen, not that it is impossible to happen.
It is easy to check when two or more threads try to access the same byte/bit to set it to 1 concurrently.
The first one I already did. Comparing the resulting binary images to be equal.
Since each thread is just a sequence of instructions. We can log each step of its insertion way and compare the results afterwards.
To be near or exact, at which step, in what quantity.
No need for debugger.
For classic BSGS it is much easier since the babyTable is just a sequence from 1 to some power of two value.
And I guess for home PC 2^40 or lower is the limit and that is with 256G RAM.
What I see good in this is that at least now started to write answers as the sane man and not some perverse nutcase.