lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <>
Subject Re: "docMap" array in SegmentMergeInfo
Date Wed, 12 Oct 2005 06:52:30 GMT

I'm pretty sure it doesn't solve the problem in general (it isn't a 
thread-save solution for sure, you mentioned the memory barrier, I'd add 
compiler optimizations). If it works it must be something 
application-specific, maybe synchronization isn't really needed there, 
or you just don't do anything (i.e. write operations) that would cause a 


Yonik Seeley wrote:
> I'm not sure that looks like a safe patch.
> Synchronization does more than help prevent races... it also introduces
> memory barriers.
> Removing synchronization to objects that can change is very tricky business
> (witness the double-checked locking antipattern).
> -Yonik
> Now hiring --
> On 10/11/05, Chris Lamprecht <> wrote:
>>Hi Peter,
>>I observed the same issue on a multiprocessor machine. I included a
>>small fix for this in the NIO patch (against the 1.9 trunk) here:
>>The change amounts to the following methods in, to
>>remove the need synchronized() block by taking a "snapshot" of the
>>// Removed synchronized from document(int)
>>public Document document(int n) throws IOException {
>>if (isDeleted(n))
>>throw new IllegalArgumentException
>>("attempt to access a deleted document");
>>return fieldsReader.doc(n);
>>// removed synchronized from isDeleted(int)
>>public boolean isDeleted(int n) {
>>// avoid race condition by getting a snapshot reference
>>final BitVector snapshot = deletedDocs;
>>return (snapshot != null && snapshot.get(n));
>>We've been using this in production for a while and it fixed the
>>extremely slow searches when there are deleted documents. Maybe it
>>could be applied to the trunk, independent of the full NIO patch.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message