Writing a value involves reading the value.
Since each thread is just a sequence of instructions. We can log each step of its insertion way and compare the results afterwards.
Yeah, but those instructions run in parallel, hence it's guaranteed that, without an access sync, at some point, a r/w race condition will occur. You should know best what'ya doin', so I won't insist.
Or are you saying this can never happen:
X = 0
Cycle T0 T1
0 read X read X // T0: is X 0 or 32? T1: is X 0 or 8?
1 set x[3] set X[5] // T0: is X 8 or 40? T1: is X 32 or 40?
2 write X write X // what X is final? what about cache lines refresh?
3 X = ???????? // one of 8, 32, or 40
It can happen. But in practice I have everything working fine.
Bloomfilters due to their multiple use of hashes to insert one element are sure to hit the same bit in the same byte or different bits in the same byte in multithreaded approach.
But no matter how many times I tested this never cause any broken state to the resulting binary image of the bloomfilter file.
And concerning my code concept bloomfilter is used excessively to compute the decimal places in order to get the index of the bloomfilter hit .
That is later used to calculate the private key.
If bloomfilter integrity was broken this would never happen.
All in all thanks for explanation. Will add mutex stuff later to make sure everything is fine.