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.