There are solutions to solve the initialization problem. The JVM guarantees
that an object is consistent after the ctor is run, so you can do the
initialization like this (please note the double {{}}, which is an inline
ctor, this is also often seen for unmodifiable HashSets):
final OpenBitSet mybits = new OpenBitSet(size) {{
fastSet(1); fastSet(2);...
}};
The same is often used for HashSets:
final Set<String> myFinalUnmodifiableSet = Collections.unmodifiableSet(new
HashSet<String>() {{
add(a); add(b); add(c);...
}});
The only thing we don't have a is a unmodifiable wrapper for OpenBitSet, but
in the above example its only there to prevent modification, but for theread
safety it has no effect (the HashSet contents do not get final by that).
In general you cannot make the bits array final at all (you can make the
reference to it final, but not the contents).
You may also review Michael Busch's talk on last Lucene Revolution / Berlin
Buzzwords on Twitter's Lucene-based Realtime Search, he explains some tricks
to make arrays threadsafe without too much locking.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -----Original Message-----
> From: Nader, John P [mailto:john.na...@cengage.com]
> Sent: Thursday, April 28, 2011 12:24 AM
> To: java-user@lucene.apache.org
> Subject: RE: Immutable OpenBitSet?
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
