Thanks. Your project looks interesting. We've got some duplicate home-grown stuff here that is similar.
As far as thread-safety, if one thread initializes an OpenBitSet's by setting one or bits and then hands that off to another thread, the other thread may see partial results. The long[] is not protected by read/write synchronization, nor does it get any of the guarantees of final. This is problematic for caching bit sets. My idea for an optimal and guaranteed thread-safe implementation would be a class nearly identical to OpenBitSet except: - Only implements read operation (gets, tests, compares, etc.) - Is constructed from an already initialized long[] or another OpenBitSet. - declares its reference to bits and wlen as final. There are a few problems with implementing equals, since that directly accesses the non-final field on OpenBitSet. -----Original Message----- From: Federico Fissore [mailto:feder...@fissore.org] Sent: Wednesday, April 27, 2011 5:12 PM To: java-user@lucene.apache.org Subject: Re: Immutable OpenBitSet? Nader, John P, il 27/04/2011 20:28, ha scritto: > Hello, > > We have an application that relies heavily on caching OpenBitSets for reuse > across multiple threads, and therefore multiple threads. [...] You don't need synchronization if you just read from an openbitset. And if you need to modify it, you can achieve thread safeness even with thread confinement. BTW (shameless plug) if you are going to operate on large sets of bitsets, you should probably take a look at https://github.com/ffissore/Parallel-Bitset-Operations we are integrating it into some of our searchers HTH federico --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
