Ninjastic
PostEdited versionsQuotes to this post
Next scheduled rescrape ... never
Version 2
Last scraped
Edited on 10/06/2025, 06:07:07 UTC
Quote from: AlexanderCurl on June 02, 2025, 04:56:02 PM
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.
Version 1
Scraped on 03/06/2025, 06:11:53 UTC
Quote from: AlexanderCurl on June 02, 2025, 04:56:02 PM
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.
Original archived Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Scraped on 03/06/2025, 06:07:05 UTC
Quote from: AlexanderCurl on June 02, 2025, 04:56:02 PM
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 bits that need to be written end up on the same cache lines of different cores, you have two different results, both wrong, and one of those will end up in your filter.