Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: "Uwe Schindler" <uwe@thetaphi.de>
To: <java-user@lucene.apache.org>
References: <70EA5691BD59734784FF872CD1B9747A28500DFDA8@OHCINMBX01.corp.local>
 <4DB8868E.8010002@fissore.org>
 <70EA5691BD59734784FF872CD1B9747A28500DFF31@OHCINMBX01.corp.local>
 <4DB9126B.8090806@fissore.org>
In-Reply-To: <4DB9126B.8090806@fissore.org>
Subject: RE: Immutable OpenBitSet?
Date: Thu, 28 Apr 2011 10:13:13 +0200
Message-ID: <005901cc057c$1f4a5330$5ddef990$@thetaphi.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AQMxmWqaxmtJlNFI4GO5PHDqBRNaoAKIeb2gApgsu64BVWwlkpF0Ek2A
Content-Language: de

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).

But in general, this is also true for any factory method: e.g. when
Filter.getDocIdSet() creates an OpenBitSet and returns it, the whole BitSet
is invisible to any other thread before it's "publihsed" by returning from
this method. So after the method returns it first gets visible. Inside the
getDocIdSet method its still private and therefore invisible to any other
thread. So the pattern of Filters creating DocIdSets is perfectly valid (and
works, as you see with CachingWrapperFilter). There is no need to
explicitely make OpenBitSets immutable. The only thing you should ensure is
that you don't modify them - and that the reason behind making it final.

As Federico said before, you should read the famous book about Java
Concurrency:
http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601

Uwe

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


> -----Original Message-----
> From: Federico Fissore [mailto:federico@fissore.org]
> Sent: Thursday, April 28, 2011 9:08 AM
> To: java-user@lucene.apache.org
> Subject: Re: Immutable OpenBitSet?
> 
> Nader, John P, il 28/04/2011 00:24, ha scritto:
> > 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.
> [...]
> 
> 
> I see your point. As Uwe said, you can safe publish an object initialized
by a
> static initializer.
>  From Java Concurrency in Practice, page 52, you read
> 
> --
> To publish an object safely, both the reference to the object and the
object's
> state must be made visible to other threads at the same time. A properly
> constructed object can be safely published by:
> . Initializing an object reference from a static initializer; . Storing a
reference
> to it into a volatile field or AtomicReference; . Storing a reference to
it into a
> final field of a properly constructed object; or . Storing a reference to
it into a
> field that is properly guarded by a lock.
> --
> 
> The last point means that if your bitset cache is backed by a synchronized
> collection, the JVM will guarantee the safe publication even of a
non-thread-
> safe objects
> 
> federico
> 
> ---------------------------------------------------------------------
> 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