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
hasheshash functions to insert one element are sure to hit the same bit in the same byte or different bits in the same byte in
multithreaded approachmulti-threaded context.
But no matter how many times I tested this never
causecaused any broken state to the resulting binary image of the bloomfilter file.
And concerning my code concept bloomfilter is used excessively to
computecount the decimal places in order to get the index of the bloomfilter hit .
That is
later used
later to calculate the private key.
If bloomfilter integrity was broken this would never happen.
All in all thanks for explanation.
Will addAdded mutex
stuff laterlocks to make sure everything is fine.