BloomFilter multithread problem: put() NOT atomic

Hello team!

I just found a problem using com.google.common.hash.BloomFilter with more than one thread. Long story short: put() is not atomic so I am able to reproduce a false negative.

This is the config in pom.xml:

<dependency>
   <groupId>com.google.guava</groupId>
   <artifactId>guava</artifactId>
   <version>24.0-jre</version>
</dependency>

I created a simple Test.java class that proves the point. The fix is also included in the file: just uncomment lines 56 and 58 (make put() synchronized).

Looking at the BloomFilter javadoc I see:

 * As of Guava 23.0, this class is thread-safe and lock-free. It internally uses atomics and
 * compare-and-swap to ensure correctness when multiple threads are used to access it.

So I suppose that I’m not doing anything “wrong”. Can you please confirm the issue or tell me where I’m using the library wrong?

Thanks!

[ben-manes]

My understanding was that thread-safe and lock-free in the JavaDoc does not guarantee that the entire operation is atomic. This allowed the small design change in #2748 to be racy, assuming that the results were overall okay.

The alternative that I proposed was more invasive, by using a Bloom-1 design. If redesigning the implementation to target concurrency, then I think it would be better to adopt that. But the goal was to expand usage to allow best effort concurrency, so the implementation change seemed reasonable as is.

[lowasser]

I’m not sure I see a thread-safe, lock-free solution that returns a meaningful value from put. We might be in a position of being forced to break one of those API specifications.