lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Immutable OpenBitSet?
Date Thu, 28 Apr 2011 13:32:42 GMT
This is all not a problem, if the reference to the newly created object is passed e.g. into
a synchronized cache (like it is done in CachingWrapperFilter). When entering the synchronized
method that adds the reference to the object to the cache (in the filter case it’s the OpenBitSet
created shortly before), a memory barrier will make the complete object with all its references
published to all.

So:

bs = new OpenBitSet();
bs.fastSet(something);
synchronized (cacheLock) {
	cache.put(rederKey, bs);
}

Is safe as after the synchronized, the memory barrier causes safe publish. This is what also
Federico Fissore said.

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de


> -----Original Message-----
> From: Trejkaz [mailto:trejkaz@trypticon.org]
> Sent: Thursday, April 28, 2011 2:45 PM
> To: java-user@lucene.apache.org
> Subject: Re: Immutable OpenBitSet?
> 
> On Thu, Apr 28, 2011 at 6:13 PM, Uwe Schindler <uwe@thetaphi.de> wrote:
> > In general a *newly* created object that was not yet seen by any other
> > thread is always safe. This is why I said, set all bits in the ctor.
> > This is easy to understand: Before the ctor returns, the object's
> > contents and all references like arrays are not seen by any other thread
> (that's guaranteed).
> 
> Section 17.5 of the JLS gives the following example:
> 
>     class FinalFieldExample {
>       final int x;
>       int y;
>       static FinalFieldExample f;
>       public FinalFieldExample() {
>         x = 3;
>         y = 4;
>       }
>       static void writer() {
>         f = new FinalFieldExample();
>       }
>       static void reader() {
>         if (f != null) {
>           int i = f.x; // guaranteed to see 3
>           int j = f.y; // could see 0
>         }
>       }
>     }
> 
> Essentially, there is no guarantee that the work in the constructor has been
> completed when another thread gets a reference to the object.
>  To make the guarantee, use the final keyword.
> 
> It seems like this contradicts the claim above, but maybe I'm missing
> something.
> 
> TX
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message